[ANN] new Symbol class and real object identity
Locked
12
12
Re: [ANN] new Symbol class and real object identity
 
|
for example, one cannot do something like:
someObject perform: #foo: withArguments: #(baz) because the colon (:) in #foo: is not recognized.
On Thu, Dec 8, 2011 at 11:28 PM, Amber Milan Eskridge <[hidden email]> wrote: In the version I currently use, I can not create Strings with colon in |
Re: [ANN] new Symbol class and real object identity
|
|
On Fri, 2011-12-09 at 23:35 +0100, Amber Milan Eskridge wrote:
> for example, one cannot do something like: > someObject perform: #foo: withArguments: #(baz) > Ah, yeah, the parser misses it. Can you add an issue on the bug tracker? Cheers, Nico > > because the colon (:) in #foo: is not recognized. > > On Thu, Dec 8, 2011 at 11:28 PM, Amber Milan Eskridge > <[hidden email]> wrote: > In the version I currently use, I can not create Strings with > colon in > them using the #-notation. > > > On Wed, Dec 7, 2011 at 10:06 PM, Nicolas Petton > <[hidden email]> wrote: > > On Wed, 2011-12-07 at 17:17 +0100, Amber Milan Eskridge > wrote: > >> One question, are #keywordMessages:withColons: as Symbols > now possible? > > > > I don't understand :) > > > >> > >> On Wed, Dec 7, 2011 at 11:18 AM, Amber Milan Eskridge > >> <[hidden email]> wrote: > >> > Wow, great news! > >> > > >> > On Tue, Dec 6, 2011 at 11:31 AM, Nicolas Petton > >> > <[hidden email]> wrote: > >> >> On Tue, 2011-12-06 at 08:00 +0100, laurent laffont > wrote: > >> >>> > >> >>> On Mon, Dec 5, 2011 at 9:57 PM, Nicolas Petton > >> >>> <[hidden email]> wrote: > >> >>> Hi, > >> >>> > >> >>> Amber got a new class: Symbol. I adapted the > parser to compile > >> >>> #foo as a > >> >>> symbol, and they perform like expected: they > are unique. > >> >>> > >> >>> Object identity has been improved, now #== > behaves like in any > >> >>> other > >> >>> Smalltalk, and test the #identityHash. Unit > tests reflect > >> >>> these changes. > >> >>> > >> >>> The Kernel now has 90 unit tests. They're all > green here, but > >> >>> if someone > >> >>> could test on safari (IE7, Laurent?) that would > be great. > >> >>> > >> >>> > >> >>> On all IE these two tests are failing: > >> >>> - BlockClosureTest>>testCompiledSource: > function(){return (1) + (1);} > >> >>> but was: function (){return (1) + (1);} > >> >>> because of a space between function and (). Do we care > about this > >> >>> space ? > >> >> > >> >> Not at all. I fixed the test. > >> >> > >> >>> - JSObjectProxyTest>>testPropertyThatReturnsEmptyString > because in IE > >> >>> hash always return at least # (I've written this test > so that crap is > >> >>> my fault :) > >> >> OK, I'll fix that. > >> >> > >> >> Nico > >> >> > >> >>> > >> >>> > >> >>> On IE7 + IE8 more failing test: > >> >>> - SymbolTest>>testAt > >> >>> - StringTest>>testAt > >> >>> - StringTest>>testCopyWithoutAll > >> >>> > >> >>> > >> >>> I will work with Amber tomorrow, I can check. > >> >>> > >> >>> > >> >>> Laurent > >> >>> > >> >>> > >> >>> Cheers, > >> >>> Nico > >> >>> > >> >>> > >> >> > >> >> > > > > > > > |
|
|
In reply to this post by Nicolas Petton
In my amber ready function I have the line:
smalltalk.OrderedCollection = smalltalk.Array now you can reference OrderedCollection anywhere you like from within Smalltalk and it just works :) Pat On Dec 7, 2011, at 4:33 AM, Nicolas Petton wrote: > You are right. Amber doesn't need OrderedCollection. But what I care > about here is compatibility. Amber should be compatible with other > dialects to some degree, and I think OrderedCollection is part of it. > > Now, does Array in Amber have to be fixed-size? Not sure. > OrderedCollection could just be there for compatibility and convenience. > > Cheers, > Nico > > On Wed, 2011-12-07 at 13:29 +0100, Amber Milan Eskridge wrote: >> As I understand it, the difference is that Arrays in Smalltalk need to >> have a fixed size because of the implementation-limitations of >> Smalltalk in 1980. OrderedCollection is an implementation of "growing >> Arrays" (using Array(s)) to circumvent this, when necessary. >> >> Because JS-Arrays will be used for the implementation of ST-Arrays and >> ST-OrderedCollections and JS-Arrays do not have the limitations of >> the 1980 ST-Arrays, OrderedCollection is not really needed(?), it >> seems to me? >> >> On Wed, Dec 7, 2011 at 12:18 PM, H. Hirzel <[hidden email]> wrote: >>> As Milan I'd like to know more about the guiding implementation principles. >>> >>> The reason might just be that existing Smalltalk code works even if >>> Array and OrderedCollection are both a JavaScript array. In that sense >>> OrderedCollection in Amber is just a synonym for Array, right? >>> >>> --Hannes >>> >>> On 12/7/11, Amber Milan Eskridge <[hidden email]> wrote: >>>> Oh :( >>>> >>>> I see no need for fixed-sized arrays since both will be implemented as >>>> JS-Arrays(?) making a distinction where none really exists with no >>>> additional benefit. As I understand it, Array and OrderedCollection >>>> are different in ST, to avoid an implementation-related >>>> performance/memory issue. Sounds therefore like Cargo-Cult-Programming >>>> for my ears. >>>> >>>> Can someone enlighten me? >>>> >>>> 2011/12/6 Göran Krampe <[hidden email]>: >>>>> On 12/06/2011 11:36 AM, Nicolas Petton wrote: >>>>>> >>>>>> Collection >>>>>> HashedCollection >>>>>> Dictionary >>>>>> Set >>>>>> SortedCollection >>>>>> SequenceableCollection >>>>>> Array >>>>>> OrderedCollection >>>>>> CharacterArray >>>>>> String >>>>>> Symbol >>>>>> >>>>>> I think we'll be good to go with this hierarchy, and compatible enough >>>>>> with the other Smalltalk dialects. >>>>> >>>>> >>>>> Bloody brilliant I tell ya! :) >>>>> >>>>> regards, Göran >>>>> >>>> > > |
Re: OrderedCollection + fixed sized Array
|
|
yeah, I know, but it means they will be both in the class browser,
referencing the *same* object. Now, why not :) Cheers, Nico On Fri, 2011-12-09 at 17:57 -0800, Pat Maddox wrote: > In my amber ready function I have the line: > smalltalk.OrderedCollection = smalltalk.Array > > now you can reference OrderedCollection anywhere you like from within Smalltalk and it just works :) > > Pat > > > On Dec 7, 2011, at 4:33 AM, Nicolas Petton wrote: > > > You are right. Amber doesn't need OrderedCollection. But what I care > > about here is compatibility. Amber should be compatible with other > > dialects to some degree, and I think OrderedCollection is part of it. > > > > Now, does Array in Amber have to be fixed-size? Not sure. > > OrderedCollection could just be there for compatibility and convenience. > > > > Cheers, > > Nico > > > > On Wed, 2011-12-07 at 13:29 +0100, Amber Milan Eskridge wrote: > >> As I understand it, the difference is that Arrays in Smalltalk need to > >> have a fixed size because of the implementation-limitations of > >> Smalltalk in 1980. OrderedCollection is an implementation of "growing > >> Arrays" (using Array(s)) to circumvent this, when necessary. > >> > >> Because JS-Arrays will be used for the implementation of ST-Arrays and > >> ST-OrderedCollections and JS-Arrays do not have the limitations of > >> the 1980 ST-Arrays, OrderedCollection is not really needed(?), it > >> seems to me? > >> > >> On Wed, Dec 7, 2011 at 12:18 PM, H. Hirzel <[hidden email]> wrote: > >>> As Milan I'd like to know more about the guiding implementation principles. > >>> > >>> The reason might just be that existing Smalltalk code works even if > >>> Array and OrderedCollection are both a JavaScript array. In that sense > >>> OrderedCollection in Amber is just a synonym for Array, right? > >>> > >>> --Hannes > >>> > >>> On 12/7/11, Amber Milan Eskridge <[hidden email]> wrote: > >>>> Oh :( > >>>> > >>>> I see no need for fixed-sized arrays since both will be implemented as > >>>> JS-Arrays(?) making a distinction where none really exists with no > >>>> additional benefit. As I understand it, Array and OrderedCollection > >>>> are different in ST, to avoid an implementation-related > >>>> performance/memory issue. Sounds therefore like Cargo-Cult-Programming > >>>> for my ears. > >>>> > >>>> Can someone enlighten me? > >>>> > >>>> 2011/12/6 Göran Krampe <[hidden email]>: > >>>>> On 12/06/2011 11:36 AM, Nicolas Petton wrote: > >>>>>> > >>>>>> Collection > >>>>>> HashedCollection > >>>>>> Dictionary > >>>>>> Set > >>>>>> SortedCollection > >>>>>> SequenceableCollection > >>>>>> Array > >>>>>> OrderedCollection > >>>>>> CharacterArray > >>>>>> String > >>>>>> Symbol > >>>>>> > >>>>>> I think we'll be good to go with this hierarchy, and compatible enough > >>>>>> with the other Smalltalk dialects. > >>>>> > >>>>> > >>>>> Bloody brilliant I tell ya! :) > >>>>> > >>>>> regards, Göran > >>>>> > >>>> > > > > > |
|
|
I think there are bigger fish to fry!
On Dec 10, 2011, at 6:19 AM, Nicolas Petton wrote: > yeah, I know, but it means they will be both in the class browser, > referencing the *same* object. > > Now, why not :) > > Cheers, > Nico > > On Fri, 2011-12-09 at 17:57 -0800, Pat Maddox wrote: >> In my amber ready function I have the line: >> smalltalk.OrderedCollection = smalltalk.Array >> >> now you can reference OrderedCollection anywhere you like from within Smalltalk and it just works :) >> >> Pat >> >> >> On Dec 7, 2011, at 4:33 AM, Nicolas Petton wrote: >> >>> You are right. Amber doesn't need OrderedCollection. But what I care >>> about here is compatibility. Amber should be compatible with other >>> dialects to some degree, and I think OrderedCollection is part of it. >>> >>> Now, does Array in Amber have to be fixed-size? Not sure. >>> OrderedCollection could just be there for compatibility and convenience. >>> >>> Cheers, >>> Nico >>> >>> On Wed, 2011-12-07 at 13:29 +0100, Amber Milan Eskridge wrote: >>>> As I understand it, the difference is that Arrays in Smalltalk need to >>>> have a fixed size because of the implementation-limitations of >>>> Smalltalk in 1980. OrderedCollection is an implementation of "growing >>>> Arrays" (using Array(s)) to circumvent this, when necessary. >>>> >>>> Because JS-Arrays will be used for the implementation of ST-Arrays and >>>> ST-OrderedCollections and JS-Arrays do not have the limitations of >>>> the 1980 ST-Arrays, OrderedCollection is not really needed(?), it >>>> seems to me? >>>> >>>> On Wed, Dec 7, 2011 at 12:18 PM, H. Hirzel <[hidden email]> wrote: >>>>> As Milan I'd like to know more about the guiding implementation principles. >>>>> >>>>> The reason might just be that existing Smalltalk code works even if >>>>> Array and OrderedCollection are both a JavaScript array. In that sense >>>>> OrderedCollection in Amber is just a synonym for Array, right? >>>>> >>>>> --Hannes >>>>> >>>>> On 12/7/11, Amber Milan Eskridge <[hidden email]> wrote: >>>>>> Oh :( >>>>>> >>>>>> I see no need for fixed-sized arrays since both will be implemented as >>>>>> JS-Arrays(?) making a distinction where none really exists with no >>>>>> additional benefit. As I understand it, Array and OrderedCollection >>>>>> are different in ST, to avoid an implementation-related >>>>>> performance/memory issue. Sounds therefore like Cargo-Cult-Programming >>>>>> for my ears. >>>>>> >>>>>> Can someone enlighten me? >>>>>> >>>>>> 2011/12/6 Göran Krampe <[hidden email]>: >>>>>>> On 12/06/2011 11:36 AM, Nicolas Petton wrote: >>>>>>>> >>>>>>>> Collection >>>>>>>> HashedCollection >>>>>>>> Dictionary >>>>>>>> Set >>>>>>>> SortedCollection >>>>>>>> SequenceableCollection >>>>>>>> Array >>>>>>>> OrderedCollection >>>>>>>> CharacterArray >>>>>>>> String >>>>>>>> Symbol >>>>>>>> >>>>>>>> I think we'll be good to go with this hierarchy, and compatible enough >>>>>>>> with the other Smalltalk dialects. >>>>>>> >>>>>>> >>>>>>> Bloody brilliant I tell ya! :) >>>>>>> >>>>>>> regards, Göran >>>>>>> >>>>>> >>> >>> >> > > |
Re: [ANN] new Symbol class and real object identity
|
|
In reply to this post by Nicolas Petton
I did :)
https://github.com/NicolasPetton/amber/issues/111 On Sat, Dec 10, 2011 at 1:46 AM, Nicolas Petton <[hidden email]> wrote:
|
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |