The Trunk: EToys-topa.121.mcz
Locked
 
|
Tobias Pape uploaded a new version of EToys to project The Trunk:
http://source.squeak.org/trunk/EToys-topa.121.mcz ==================== Summary ==================== Name: EToys-topa.121 Author: topa Time: 3 April 2015, 12:20:38.114 am UUID: d3f4e3f2-9ef0-4138-89d2-a88d122f9bc6 Ancestors: EToys-topa.120 As Etoys is not _per se_ dependent on Sound, be graceful about its presence in Etoys' tests. =============== Diff against EToys-topa.120 =============== Item was added: + ----- Method: TileMorphTest>>expectedFailures (in category 'testing') ----- + expectedFailures + + ^ super expectedFailures, + ((Smalltalk hasClassNamed: 'BaseSoundSystem') + ifTrue: [#()] + ifFalse: [#(testSoundTile) "Only this test depends on Sound"])! Item was changed: ----- Method: TileMorphTest>>setUp (in category 'running') ----- setUp self soundSystemBackup: SoundService defaultOrNil. + SoundService default: (Smalltalk classNamed: 'BaseSoundSystem').! - SoundService default: BaseSoundSystem.! |
Re: The Trunk: EToys-topa.121.mcz
|
|
I prefer to use Symbols instead of Strings for class names, because they
make it easier to find potential users of the class. Levente On Thu, 2 Apr 2015, [hidden email] wrote: > Tobias Pape uploaded a new version of EToys to project The Trunk: > http://source.squeak.org/trunk/EToys-topa.121.mcz > > ==================== Summary ==================== > > Name: EToys-topa.121 > Author: topa > Time: 3 April 2015, 12:20:38.114 am > UUID: d3f4e3f2-9ef0-4138-89d2-a88d122f9bc6 > Ancestors: EToys-topa.120 > > As Etoys is not _per se_ dependent on Sound, be graceful about its presence in Etoys' tests. > > =============== Diff against EToys-topa.120 =============== > > Item was added: > + ----- Method: TileMorphTest>>expectedFailures (in category 'testing') ----- > + expectedFailures > + > + ^ super expectedFailures, > + ((Smalltalk hasClassNamed: 'BaseSoundSystem') > + ifTrue: [#()] > + ifFalse: [#(testSoundTile) "Only this test depends on Sound"])! > > Item was changed: > ----- Method: TileMorphTest>>setUp (in category 'running') ----- > setUp > > self soundSystemBackup: SoundService defaultOrNil. > + SoundService default: (Smalltalk classNamed: 'BaseSoundSystem').! > - SoundService default: BaseSoundSystem.! > > > |
Re: The Trunk: EToys-topa.121.mcz
|
|
Hi,
On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: > I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. > yes, but #hasClassNamed: is a String protocol. What do you suggest? Smalltalk>>#at: ? > Levente > > On Thu, 2 Apr 2015, [hidden email] wrote: > >> Tobias Pape uploaded a new version of EToys to project The Trunk: >> http://source.squeak.org/trunk/EToys-topa.121.mcz >> >> ==================== Summary ==================== >> >> Name: EToys-topa.121 >> Author: topa >> Time: 3 April 2015, 12:20:38.114 am >> UUID: d3f4e3f2-9ef0-4138-89d2-a88d122f9bc6 >> Ancestors: EToys-topa.120 >> >> As Etoys is not _per se_ dependent on Sound, be graceful about its presence in Etoys' tests. >> >> =============== Diff against EToys-topa.120 =============== >> >> Item was added: >> + ----- Method: TileMorphTest>>expectedFailures (in category 'testing') ----- >> + expectedFailures >> + >> + ^ super expectedFailures, >> + ((Smalltalk hasClassNamed: 'BaseSoundSystem') >> + ifTrue: [#()] >> + ifFalse: [#(testSoundTile) "Only this test depends on Sound"])! >> >> Item was changed: >> ----- Method: TileMorphTest>>setUp (in category 'running') ----- >> setUp >> >> self soundSystemBackup: SoundService defaultOrNil. >> + SoundService default: (Smalltalk classNamed: 'BaseSoundSystem').! >> - SoundService default: BaseSoundSystem.! |
Re: The Trunk: EToys-topa.121.mcz
|
|
On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote:
> Hi, > > On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: > >> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. +1 > yes, but #hasClassNamed: is a String protocol. A Symbol is a String. Many (if not all) existing users of hasClassNamed: pass Symbols (a special kind of String). |
Re: The Trunk: EToys-topa.121.mcz
|
|
On 03.04.2015, at 01:00, Chris Muller <[hidden email]> wrote: > On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote: >> Hi, >> >> On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: >> >>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. > > +1 > >> yes, but #hasClassNamed: is a String protocol. > > A Symbol is a String. Many (if not all) existing users of > hasClassNamed: pass Symbols (a special kind of String). I don't want to rely on that. Symbols being Strings is an implementation detail. Looking at the broader picture, in GemStone, in fact a Symbol is not a String. Best -Tobias |
Re: The Trunk: EToys-topa.121.mcz
|
|
2015-04-03 1:32 GMT+02:00 Tobias Pape <[hidden email]>:
Yes, but String/Symbol equality is an implementation detail. In Visualworks 'foo' ~= #foo. |
Re: The Trunk: EToys-topa.121.mcz
|
|
In reply to this post by Tobias Pape
On Thu, Apr 2, 2015 at 6:32 PM, Tobias Pape <[hidden email]> wrote:
> > On 03.04.2015, at 01:00, Chris Muller <[hidden email]> wrote: > >> On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote: >>> Hi, >>> >>> On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: >>> >>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. >> >> +1 >> >>> yes, but #hasClassNamed: is a String protocol. >> >> A Symbol is a String. Many (if not all) existing users of >> hasClassNamed: pass Symbols (a special kind of String). > > I don't want to rely on that. > Symbols being Strings is an implementation detail. Symbols logically ARE Strings, regardless of implementation. They're a series of characters just canonicalized. Its only the canonicalization that's implementation-specific, not equality or type testing.. > Looking at the broader picture, in GemStone, in fact > a Symbol is not a String. Object name "#Object" <---- a Symbol. So why do you say #hasClassNamed: a "String protocol" instead of a "Symbol protocol"? |
Re: The Trunk: EToys-topa.121.mcz
|
|
On 03.04.2015, at 01:44, Chris Muller <[hidden email]> wrote: > On Thu, Apr 2, 2015 at 6:32 PM, Tobias Pape <[hidden email]> wrote: >> >> On 03.04.2015, at 01:00, Chris Muller <[hidden email]> wrote: >> >>> On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote: >>>> Hi, >>>> >>>> On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: >>>> >>>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. >>> >>> +1 >>> >>>> yes, but #hasClassNamed: is a String protocol. >>> >>> A Symbol is a String. Many (if not all) existing users of >>> hasClassNamed: pass Symbols (a special kind of String). >> >> I don't want to rely on that. >> Symbols being Strings is an implementation detail. > > Symbols logically ARE Strings, regardless of implementation. They're > a series of characters just canonicalized. Its only the > canonicalization that's implementation-specific, not equality or type > testing.. Nope. The idea of a symbol is (IMHO, admittedly) broader than just canonicalized Strings. If it where, I would call it InternedString or CanonicalizedString. Symbols are unique human readable identifiers. See Prolog, where the concept is called Atoms. There is no conceptual differences. Yet, Prolog atoms do not remotely compare to interned strings. > >> Looking at the broader picture, in GemStone, in fact >> a Symbol is not a String. > > Object name "#Object" <---- a Symbol. > > So why do you say #hasClassNamed: a "String protocol" instead of a > "Symbol protocol"? See #classOrTraitNamed: (which is called by #classNamed:) classOrTraitNamed: aString "aString is either a class or trait name or a class or trait name followed by ' class' or 'classTrait' respectively. Answer the class or metaclass it names." and hasClassNamed: aString "Answer whether there is a class of the given name, but don't intern aString if it's not alrady interned. 4/29/96 sw" Best -Tobias |
Re: The Trunk: EToys-topa.121.mcz
|
|
2015-04-03 1:52 GMT+02:00 Tobias Pape <[hidden email]>:
To me, the idea to not intern 'BaseSoundSystem' is moot. We blatantly have a reference to #BaseSoundSystem that we try to hide. Why? Nicolas |
Re: The Trunk: EToys-topa.121.mcz
|
|
On 03.04.2015, at 02:39, Nicolas Cellier <[hidden email]> wrote: > > > 2015-04-03 1:52 GMT+02:00 Tobias Pape <[hidden email]>: > > On 03.04.2015, at 01:44, Chris Muller <[hidden email]> wrote: > > > On Thu, Apr 2, 2015 at 6:32 PM, Tobias Pape <[hidden email]> wrote: > >> > >> On 03.04.2015, at 01:00, Chris Muller <[hidden email]> wrote: > >> > >>> On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote: > >>>> Hi, > >>>> > >>>> On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: > >>>> > >>>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. > >>> > >>> +1 > >>> > >>>> yes, but #hasClassNamed: is a String protocol. > >>> > >>> A Symbol is a String. Many (if not all) existing users of > >>> hasClassNamed: pass Symbols (a special kind of String). > >> > >> I don't want to rely on that. > >> Symbols being Strings is an implementation detail. > > > > Symbols logically ARE Strings, regardless of implementation. They're > > a series of characters just canonicalized. Its only the > > canonicalization that's implementation-specific, not equality or type > > testing.. > > Nope. The idea of a symbol is (IMHO, admittedly) broader than > just canonicalized Strings. If it where, I would call it InternedString > or CanonicalizedString. Symbols are unique human readable identifiers. > > See Prolog, where the concept is called Atoms. There is no conceptual > differences. Yet, Prolog atoms do not remotely compare to interned strings. > > > > >> Looking at the broader picture, in GemStone, in fact > >> a Symbol is not a String. > > > > Object name "#Object" <---- a Symbol. > > > > So why do you say #hasClassNamed: a "String protocol" instead of a > > "Symbol protocol"? > > See #classOrTraitNamed: (which is called by #classNamed:) > > classOrTraitNamed: aString > "aString is either a class or trait name or a class or trait name followed by ' class' or 'classTrait' respectively. > Answer the class or metaclass it names." > > and > > hasClassNamed: aString > "Answer whether there is a class of the given name, but don't intern aString if it's not alrady interned. 4/29/96 sw" > > > Best > -Tobias > > > > To me, the idea to not intern 'BaseSoundSystem' is moot. > We blatantly have a reference to #BaseSoundSystem that we try to hide. Why? Nothing in particular. How would you write that? Best -Tobias |
Re: The Trunk: EToys-topa.121.mcz
|
|
In reply to this post by Tobias Pape
>>>>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class.
>>>> >>>> +1 >>>> >>>>> yes, but #hasClassNamed: is a String protocol. >>>> >>>> A Symbol is a String. Many (if not all) existing users of >>>> hasClassNamed: pass Symbols (a special kind of String). >>> >>> I don't want to rely on that. >>> Symbols being Strings is an implementation detail. >> >> Symbols logically ARE Strings, regardless of implementation. They're >> a series of characters just canonicalized. Its only the >> canonicalization that's implementation-specific, not equality or type >> testing.. > > Nope. The idea of a symbol is (IMHO, admittedly) broader than > just canonicalized Strings. If it where, I would call it InternedString > or CanonicalizedString. Symbols are unique human readable identifiers. > > See Prolog, where the concept is called Atoms. There is no conceptual > differences. Yet, Prolog atoms do not remotely compare to interned strings. I may be missing your point -- Prolog and Gemstone and Ruby and Lisp all have different semantics for many types not just Symbols. If you want to try to match an ethereal notion of some Squeak types to other languages, TileMorphTest is not quite the best place to start is it? ;-) Such a daunting mission would need to be thought out and planned at a system-wide level.. In the meantime, what about consistency of the code within the image? And about Levente's point about tool support? >>> Looking at the broader picture, in GemStone, in fact >>> a Symbol is not a String. >> >> Object name "#Object" <---- a Symbol. >> >> So why do you say #hasClassNamed: a "String protocol" instead of a >> "Symbol protocol"? > > See #classOrTraitNamed: (which is called by #classNamed:) > > classOrTraitNamed: aString > "aString is either a class or trait name or a class or trait name followed by ' class' or 'classTrait' respectively. > Answer the class or metaclass it names." > > and > > hasClassNamed: aString > "Answer whether there is a class of the given name, but don't intern aString if it's not alrady interned. 4/29/96 sw" Class #name's are Squeak Symbol's, which are just as capable of (and, responsible for) naming something as a String is. The API's above support Strings for *convenience* (in case you got it from a file or something, so you don't have to send #asSymbol first). When you create a new class, you use a Symbol to define the #name, don't you? Object subclass: #MyObject instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'MyApp' Why would Smalltalk be designed to use Symbols for the class 'creating' API and Strings for its accessing API? It makes no sense and renders the tools impotent. You are brilliant Tobias but I think we don't understand your reasoning this time.. |
Re: The Trunk: EToys-topa.121.mcz
|
|
In reply to this post by Tobias Pape
On Fri, 3 Apr 2015, Tobias Pape wrote:
> > On 03.04.2015, at 01:00, Chris Muller <[hidden email]> wrote: > >> On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote: >>> Hi, >>> >>> On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: >>> >>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. >> >> +1 >> >>> yes, but #hasClassNamed: is a String protocol. >> >> A Symbol is a String. Many (if not all) existing users of >> hasClassNamed: pass Symbols (a special kind of String). > > I don't want to rely on that. > Symbols being Strings is an implementation detail. > Looking at the broader picture, in GemStone, in fact > a Symbol is not a String. This code is not intended to be portable to other dialects, so IMHO it's fine to use Symbols as Strings. If we ever decide to make Symbols to not be Strings anymore, then we'll have to scan the image (and external packages) anyway. Levente > > Best > -Tobias > |
Re: The Trunk: EToys-topa.121.mcz
|
|
Hey
On 03.04.2015, at 17:25, Levente Uzonyi <[hidden email]> wrote: > On Fri, 3 Apr 2015, Tobias Pape wrote: > >> >> On 03.04.2015, at 01:00, Chris Muller <[hidden email]> wrote: >> >>> On Thu, Apr 2, 2015 at 5:52 PM, Tobias Pape <[hidden email]> wrote: >>>> Hi, >>>> >>>> On 03.04.2015, at 00:32, Levente Uzonyi <[hidden email]> wrote: >>>> >>>>> I prefer to use Symbols instead of Strings for class names, because they make it easier to find potential users of the class. >>> >>> +1 >>> >>>> yes, but #hasClassNamed: is a String protocol. >>> >>> A Symbol is a String. Many (if not all) existing users of >>> hasClassNamed: pass Symbols (a special kind of String). >> >> I don't want to rely on that. >> Symbols being Strings is an implementation detail. >> Looking at the broader picture, in GemStone, in fact >> a Symbol is not a String. > > This code is not intended to be portable to other dialects, so IMHO it's fine to use Symbols as Strings. If we ever decide to make Symbols to not be Strings anymore, then we'll have to scan the image (and external packages) anyway. We have several things here: 1. Symbols vs. Strings 2. How to reference a class indirectly 3. Consistent idiomatic code My code was because of a mixture of all three. I started with 2, thought about 3 and ended up with #hasClassNamed:, and due to 1 I used the code as is. Yes, I'll change it. But let me explain. I try write code that should be read. So, #hasClassNamed:/#classNamed: is undoubtedly more intention-revealing than the pseudo-Dictionary API. Now I saw that #hasClassNamed is a String API (it really is) and remembered that, while I can treat strings and symbols as same in Squeak, it is unportable[1] and I don't want to write unportable code unless I have to or it is reallly convenient. Yes, it is actually fine to write the convenient code in this place. (I'll change it :) But probably we have to think about the String/Symbol thing once again. If we perpetuate this implicit assumption throughout the core, I think we only encourage people to write unportable code, which I think would be really sad. [1]: ANSIs only requirement to both String and Symbol is that they conform to the <readableString> protocol, ie, they both answer correctly to #asString and #asSymbol. Really, I looked it up. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |