[Pharo-project] Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... )
Hi nicolas I saw the following: Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... ) Now I recall why I introduced anArray (....) for printing. This is for case where the { . } does not work. Imagine that you have an object that does not have a printing version The key point of the design of self evaluating was that you could select an expression ie {10@20 . 30@20} and print it and get the same object this way we could manipulate a lot of objects much better in an inspector or debugger. So if we { anObjectWithAWrongForm . 10@20} it defeats the purpose of self evaluating. since there are situations like that anyway this is why we decided to have anArray( ....) to really indicate that this could not be self evaluating. The form #() and {} on the other sides where always something that we could manipulate. so I had the impression that fixing some classes would be nicer than removing the distinction. Stef
OK, then the selfEvaluatingForm should better send storeOn: in order to handle parenthesis problems. Nicolas 2009/11/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi nicolas
I saw the following: Â Â Â Â Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... )
Now I recall why I introduced anArray (....) for printing. This is for case where the { . } does not work.
Imagine that you have an object that does not have a printing version
The key point of the design of self evaluating was that you could select an expression ie
{10@20 . 30@20} and print it and get the same object this way we could manipulate a lot of objects much better in an inspector or debugger.
So if we { anObjectWithAWrongForm . 10@20} it defeats the purpose of self evaluating. since there are situations like that anyway this is why we decided to have anArray( ....) to really indicate that this could not be self evaluating.
The form #() and {} on the other sides where always something that we could manipulate. so I had the impression that fixing some classes would be nicer than removing the distinction.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
probably. Stef On Nov 1, 2009, at 11:43 AM, Nicolas Cellier wrote:
OK, then the selfEvaluatingForm should better send storeOn: in order to handle parenthesis problems.
Nicolas
2009/11/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi nicolas
I saw the following: Print all Array either as literal form #( ... ) or brace form { ... } and abandon the default form anArray( ... )
Now I recall why I introduced anArray (....) for printing. This is for case where the { . } does not work.
Imagine that you have an object that does not have a printing version
The key point of the design of self evaluating was that you could select an expression ie
{10@20 . 30@20} and print it and get the same object this way we could manipulate a lot of objects much better in an inspector or debugger.
So if we { anObjectWithAWrongForm . 10@20} it defeats the purpose of self evaluating. since there are situations like that anyway this is why we decided to have anArray( ....) to really indicate that this could not be self evaluating.
The form #() and {} on the other sides where always something that we could manipulate. so I had the impression that fixing some classes would be nicer than removing the distinction.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Nicolas Cellier -
Stéphane Ducasse