[Pharo-project] Collection extensions
Hi all I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy: http://code.google.com/p/pharo/issues/detail?id=432&colspec=ID%20Type%20Stat... I would like to have your feedback because we found them really useful in practice. Here are some examples: testFlatCollectArray "self debug: #testFlatCollectArray" self assert: ((#((1 2) (3 4) (5 3)) flatCollect: [ :each ]) = #(1 2 3 4 5 3)). self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each]) = #(1 2 2 3 1 3 4)). self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each| Set with: each]) = #(#(1 2) #(2 3) #(1 3 4))). testFlatCollectSet "self debug: #testFlatCollectSet" self assert: ((#((1 2) (1 2) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). self assert: ((#() asSet flatCollect: [:each]) = #() asSet). self assert: ((#((1 2) () (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). self assert: ((#((1 2) #((99)) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4 (99)) asSet). self assert: ((#((1 2) #(()) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4 ()) asSet). testGroupedByArray "self debug: #testGroupedByArray" | res | res := #(1 2 3 4 5) groupedBy: [:each | each odd]. self assert: (res at: true) = #(1 3 5). self assert: (res at: false) = #(2 4) testGroupedBy "self debug: #testGroupedBy" | res | res := #(1 2 3 4 5) asOrderedCollection groupedBy: [:each | each odd]. self assert: (res at: true) = #(1 3 5) asOrderedCollection. self assert: (res at: false) = #(2 4) asOrderedCollection
I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy:
I think Squeak already has far too many of these methods. I would rather like to see them all removed, than new ones added. As an author and maintainer of many Smalltalk framework I experience daily the pain such methods cause, as they are inherently non-portable not only between smalltalk dialects but even between users of exactly the same image. Let me give you an example: Seaside used SequenceableCollection>>#pairsDo: in various places. The we got complaints that almost all Smalltalk platforms already provide such a method, but they all implement it entirely different. Some iterate over the combinatorial pairs, some over the consecutive pairs, some ignore an odd number of arguments, some raise an exception, etc. At some point we learned that a famous company using Seaside has their own proprietary override of this method. Today we use the ANSI #to:do:. It is ugly, but it works everywhere as it is part of ANSI Smalltalk. I would prefer to have such extension methods separate from the core. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Jan 5, 2009, at 3:56 PM, Lukas Renggli wrote:
I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy:
I think Squeak already has far too many of these methods. I would rather like to see them all removed, than new ones added. As an author and maintainer of many Smalltalk framework I experience daily the pain such methods cause, as they are inherently non-portable not only between smalltalk dialects but even between users of exactly the same image.
But these ones are since they are coming from VisualWorks.
Let me give you an example: Seaside used SequenceableCollection>>#pairsDo: in various places. The we got complaints that almost all Smalltalk platforms already provide such a method, but they all implement it entirely different. Some iterate over the combinatorial pairs, some over the consecutive pairs, some ignore an odd number of arguments, some raise an exception, etc. At some point we learned that a famous company using Seaside has their own proprietary override of this method. Today we use the ANSI #to:do:. It is ugly, but it works everywhere as it is part of ANSI Smalltalk.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body. Stef
On Mon, Jan 5, 2009 at 3:06 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 5, 2009, at 3:56 PM, Lukas Renggli wrote:
I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy:
I think Squeak already has far too many of these methods. I would rather like to see them all removed, than new ones added. As an author and maintainer of many Smalltalk framework I experience daily the pain such methods cause, as they are inherently non-portable not only between smalltalk dialects but even between users of exactly the same image.
But these ones are since they are coming from VisualWorks.
Let me give you an example: Seaside used SequenceableCollection>>#pairsDo: in various places. The we got complaints that almost all Smalltalk platforms already provide such a method, but they all implement it entirely different. Some iterate over the combinatorial pairs, some over the consecutive pairs, some ignore an odd number of arguments, some raise an exception, etc. At some point we learned that a famous company using Seaside has their own proprietary override of this method. Today we use the ANSI #to:do:. It is ugly, but it works everywhere as it is part of ANSI Smalltalk.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
Would it not be possible to implement a macro refactoring at a package level that walks the package looking for non ANSI compatible messages sent to collections and suggests appropriate inlinings to make things compliant (or at least flags up problematic methods). That way implementers who use Pharo as their development platform can work with the Pharo specific extensions as they develop, but can publish variants of the code that are ANSI compliant. No, I don't have the skills to implement such a thing, but I'm sure they could be acquired.
I vote to get these methods in. Alexandre On 5 Jan 2009, at 10:30, Stéphane Ducasse wrote:
Hi all
I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy:
http://code.google.com/p/pharo/issues/detail?id=432&colspec=ID%20Type%20Stat... I would like to have your feedback because we found them really useful in practice.
Here are some examples:
testFlatCollectArray "self debug: #testFlatCollectArray"
self assert: ((#((1 2) (3 4) (5 3)) flatCollect: [ :each ]) = #(1 2 3 4 5 3)). self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each]) = #(1 2 2 3 1 3 4)).
self assert: ((#((1 2) (2 3) (1 3 4)) flatCollect: [:each| Set with: each]) = #(#(1 2) #(2 3) #(1 3 4))).
testFlatCollectSet "self debug: #testFlatCollectSet"
self assert: ((#((1 2) (1 2) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). self assert: ((#() asSet flatCollect: [:each]) = #() asSet).
self assert: ((#((1 2) () (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4) asSet). self assert: ((#((1 2) #((99)) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4 (99)) asSet). self assert: ((#((1 2) #(()) (1 3 4)) asSet flatCollect: [:each]) = #(1 1 2 3 4 ()) asSet).
testGroupedByArray "self debug: #testGroupedByArray"
| res | res := #(1 2 3 4 5) groupedBy: [:each | each odd]. self assert: (res at: true) = #(1 3 5). self assert: (res at: false) = #(2 4)
testGroupedBy "self debug: #testGroupedBy"
| res | res := #(1 2 3 4 5) asOrderedCollection groupedBy: [:each | each odd]. self assert: (res at: true) = #(1 3 5) asOrderedCollection. self assert: (res at: false) = #(2 4) asOrderedCollection
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Maybe some lint rules could detect the usage of non portable methods... Alexandre On 5 Jan 2009, at 11:56, Lukas Renggli wrote:
I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy:
I think Squeak already has far too many of these methods. I would rather like to see them all removed, than new ones added. As an author and maintainer of many Smalltalk framework I experience daily the pain such methods cause, as they are inherently non-portable not only between smalltalk dialects but even between users of exactly the same image.
Let me give you an example: Seaside used SequenceableCollection>>#pairsDo: in various places. The we got complaints that almost all Smalltalk platforms already provide such a method, but they all implement it entirely different. Some iterate over the combinatorial pairs, some over the consecutive pairs, some ignore an odd number of arguments, some raise an exception, etc. At some point we learned that a famous company using Seaside has their own proprietary override of this method. Today we use the ANSI #to:do:. It is ugly, but it works everywhere as it is part of ANSI Smalltalk.
I would prefer to have such extension methods separate from the core.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Stef, Stéphane Ducasse wrote:
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
One of Pharo goals is to become a professional tool for serious development, specially for web apps. This implies that it should be conservative regarding introducing new and specially incompatible extensions. Because web apps are destined to be portable, so Pharo shall behave nice to other Smalltalks and avoid introducing some completely different methods in basic classes. But on the other side I agree with you, Pharo shall not be tied with that requirement too much and shall extend itself. Kind of tagging of methods as portable, pharo only etc. can therefore be a solution. Alexandre's proposal with Lint rules sounds good to me too. I would also suggest to do some promotion of good extensions to other Smalltalks as well. That way slowly Smalltalk as a whole will evolve! Pharo is right now in wonderful position to achieve such a common good for Smalltalk! Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
Can't remember the number of times I've had to implement these kinds of generally useful methods on various Smalltalk dialects (particularly #groupedBy:, called it #categorizedBy: myself ;-) ). Really should be part of all Smalltalks. I'd push for general adoption/standardisation for every dialect! That's the only way Smalltalk is going to evolve, the "ANSI standard" is years behind! Regards, Gary.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+ 1 On 5 Jan 2009, at 14:53, Gary Chambers wrote:
Can't remember the number of times I've had to implement these kinds of generally useful methods on various Smalltalk dialects (particularly #groupedBy:, called it #categorizedBy: myself ;-) ). Really should be part of all Smalltalks. I'd push for general adoption/standardisation for every dialect! That's the only way Smalltalk is going to evolve, the "ANSI standard" is years behind!
Regards, Gary.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In a similar vein, one I have found useful with the Report Builder for enablement of toolbar buttons/menu options in a multiple selection case: isHomogeneous: aBlock "Answer whether the result of evaluating the given block for each element of the receiver has the same value in each case." |val| self ifEmpty: [^true]. val := aBlock value: self anyOne. ^self allSatisfy: [:e | (aBlock value: e) = val] Regards, Gary. ----- Original Message ----- From: "Alexandre Bergel" <alexandre@bergel.eu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, January 05, 2009 6:02 PM Subject: Re: [Pharo-project] Collection extensions
+ 1
On 5 Jan 2009, at 14:53, Gary Chambers wrote:
Can't remember the number of times I've had to implement these kinds of generally useful methods on various Smalltalk dialects (particularly #groupedBy:, called it #categorizedBy: myself ;-) ). Really should be part of all Smalltalks. I'd push for general adoption/standardisation for every dialect! That's the only way Smalltalk is going to evolve, the "ANSI standard" is years behind!
Regards, Gary.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Interesting to see that you need that kind of check. Could you explain why? a button could return something else that a boolean ? On Jan 5, 2009, at 7:28 PM, Gary Chambers wrote:
In a similar vein, one I have found useful with the Report Builder for enablement of toolbar buttons/menu options in a multiple selection case:
isHomogeneous: aBlock "Answer whether the result of evaluating the given block for each element of the receiver has the same value in each case."
|val| self ifEmpty: [^true]. val := aBlock value: self anyOne. ^self allSatisfy: [:e | (aBlock value: e) = val]
Regards, Gary.
----- Original Message ----- From: "Alexandre Bergel" <alexandre@bergel.eu> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, January 05, 2009 6:02 PM Subject: Re: [Pharo-project] Collection extensions
+ 1
On 5 Jan 2009, at 14:53, Gary Chambers wrote:
Can't remember the number of times I've had to implement these kinds of generally useful methods on various Smalltalk dialects (particularly #groupedBy:, called it #categorizedBy: myself ;-) ). Really should be part of all Smalltalks. I'd push for general adoption/standardisation for every dialect! That's the only way Smalltalk is going to evolve, the "ANSI standard" is years behind!
Regards, Gary.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ 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
for these methods I could provide extensions for VW with test. I think that they are important. And I agree with Gary.
Can't remember the number of times I've had to implement these kinds of generally useful methods on various Smalltalk dialects (particularly #groupedBy:, called it #categorizedBy: myself ;-) ). Really should be part of all Smalltalks. I'd push for general adoption/standardisation for every dialect! That's the only way Smalltalk is going to evolve, the "ANSI standard" is years behind!
Regards, Gary.
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter? Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out. I do not write code to be portable to VisualWorks so?
I would prefer to have such extension methods separate from the core.
Me not. Because then in a lot of places I will have to inline their body.
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
For me this is a problem of forces that do not easily resolve. If I read the goals from the Pharo site 1...a clean and lean open-source Smalltalk platform, derived from Squeak 2...the obvious choice for professional Smalltalk development 3...an emerging platform to help people invent the future they provide different tensions. #1 encourages developers to submit changes and to become engaged and active owners of the system. It particularly provides an avenue for those frustrated with 'un-clean' Smalltalks. #2 encourages a certain compatibility amongst dialects. #3 encourages perhaps a more liberal or radical attitude to change. I do understand the problem Lukas outlines, after all I contributed to the pairsDo: problem by porting a version of Seaside to a very extended application platform ;-) However, I don't think it practical to 'ban' things. I would prefer to see, longer term, something much more radical to solving this problem. I do not particularly care for portability outwards from Pharo, but I would like to be able to run existing Smalltalk frameworks in some form of a sandbox. The functional / modular ideas expressed in Newspeak from what I've seen are fundamentally better in this regard. Classboxes was also looking at this problem? Trying to negotiate a flat selector namespace and semantics amongst dialects might be a short term solution to encourage #2 but is not doing anything interesting for #3. cheers, Mike
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter?
You are right, this change does not harm anyone not using the method. We'll have to update our tests of methods not to be sent. Still, I would rather like to see methods removed from Collection than added.
Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out.
The problem is that such message sends can't be reliably detected statically. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi Folks, I recall some time ago discussing extensions like split: and join: for OrderedCollections to better support string operations typically supported in scripting languages. Maybe we need to take a deeper look at how best to refresh the Collections framework in Pharo to modernize it, yet without breaking the ANSI standard ... There are a lot of good suggestions here, but since Collections are central to everything in Smalltalk, I think it would be wise if we step back and consider how best to proceed. The issues appear to be: - stripping out obsolete junk - conformance to ANSI standard - traits refactoring - useful String extensions (based on similar interfaces in perl, Ruby etc.) - other useful collection extension (ditto) Did I miss something? We can't do all of these at once, but we do need to make progress ... What is the best way to go ahead? - on
On Jan 6, 2009, at 8:04 AM, Lukas Renggli wrote:
So why do we do pharo. Really. If everything as to be compatible with other smalltalk. Terrible. Can't we get smarter?
You are right, this change does not harm anyone not using the method.
We'll have to update our tests of methods not to be sent.
Still, I would rather like to see methods removed from Collection than added.
Yes can you make a list of the ones that are conflicting with other implementations?
Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out.
The problem is that such message sends can't be reliably detected statically.
I lost me here. Stef
Yes can you make a list of the ones that are conflicting with other implementations?
Well, unfortunately these are all methods that are not specified in the ANSI standard.
Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out.
The problem is that such message sends can't be reliably detected statically.
I lost me here.
I was commenting on the suggestion to check possible incompatibilities when saving a package. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Jan 6, 2009, at 9:45 AM, Oscar Nierstrasz wrote:
Hi Folks,
I recall some time ago discussing extensions like split: and join: for OrderedCollections to better support string operations typically supported in scripting languages. Maybe we need to take a deeper look at how best to refresh the Collections framework in Pharo to modernize it, yet without breaking the ANSI standard ...
Yes. I would like that we move on this one too.
There are a lot of good suggestions here, but since Collections are central to everything in Smalltalk, I think it would be wise if we step back and consider how best to proceed.
We started by writing tests tests and tests. The idea is to have a good coverage of the collections and identify also the problems. This is what we are currently doing. We are writing traits and composing them to reuse tests across multiple test case. If you want to join you can publish in the pharoInbox. I think that in the process we will then identify misplaced/to remove method
The issues appear to be:
- stripping out obsolete junk - conformance to ANSI standard - traits refactoring - useful String extensions (based on similar interfaces in perl, Ruby etc.) - other useful collection extension (ditto)
Did I miss something?
We can't do all of these at once, but we do need to make progress ... What is the best way to go ahead?
Right now looking at the trait tests we implemented and improve them (add more tests add new trait tests and use the trait tests to better cover the system).
- on
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Maybe the solution is to have a downloadable package
Why can't we tag the methods with <notAnsi> and build a tool that check when you do a fill out.
The problem is that such message sends can't be reliably detected statically.
You're right, but a fairly good approximation can be made. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jan 5, 2009, at 7:56 AM, Lukas Renggli wrote:
I published to the inbox some cool collection extension methods that we use all the time in Moose. flatCollect:, collectAsSet:, and groupedBy:
I think Squeak already has far too many of these methods. I would rather like to see them all removed, than new ones added. As an author and maintainer of many Smalltalk framework I experience daily the pain such methods cause, as they are inherently non-portable not only between smalltalk dialects but even between users of exactly the same image.
(This rambles a bit, so bear with me... ) I agree with Lukas as far as what is the core system; I also used many of the unique and helpful methods available in Squeak and not in other Smalltalk implementations *as long as I know I'm not porting it another system*. With the ever improving Installer/Universes/SM system, can we not easily keep the core small and add collection extensions and other extensions as dependencies for a given package? Another option would be to change/rename the categories to denote ansi compliant methods, but since the categories metaphor is flat, methods can't be in more that one at a time. Could the OB smart filters be used in this way? Or would we have to implement some sort of tagging framework to be able to arbitrarily tag methods and classes, so methods can reside in appropriate categories and still be flagged as ANSI (among other things). I also agree with the sentiment (to a point) in the thread that ANSI is old and outdated, and why does Pharo have to be hobbled by that. From a practical matter, regardless of how old the ANSI standard is, it is the only standard we have, and when you are doing a framework like Seaside, or any number of others, compatibility with other Smalltalks where possible is extremely important. My 2 bits... - Brian
participants (10)
-
Alexandre Bergel -
Alexandre Bergel -
Brian Brown -
Gary Chambers -
Janko Mivšek -
Lukas Renggli -
Michael Roberts -
Oscar Nierstrasz -
Piers Cawley -
Stéphane Ducasse