Object>>className
Locked
12
12
 
|
Hi All,
I find Object>>#className offensive; is methods are far nicer than this nonsense. First of all className is implemented in several Monticello classes to do what you'd expect; answer the name of a class of some to-be-imported item such as a method or class definition. Second, there are tests out there that simply don't do what a naive reading might expect: testClassCommentAnnotation | annotation | browser selectSystemCategory: browser class category. browser selectClass: browser class. annotation := browser annotationForClassCommentFor: browser class. self assert: (annotation includesSubstring: browser class organization commentStamp). self assert: (annotation includesSubstring: 'class comment for'). self assert: (annotation includesSubstring: browser className). Is it /really/ that hard to write foo class name instead of foo className and have subclasses prevented from using it easily e.g. when one tries to do "create inst var accessors" for a class that one has added a className inst var? We already have Object>>#name, which is horrible enough. Ca we think seriously about nuking Object>>#className? The grouch. _,,,^..^,,,_ best, Eliot |
|
|
Hi Eliot,
Object>>#name is a travesty, but #className seems perfectly reasonable. Did you notice the comment of the method? -- it has nothing to do with "is" testing, but for accessing the type names of objects for a list, useful for presenting a list classes which could be the receiver for constructor of more objects. I have overrides of #className in some of the Ma Serializer classes, it's never presented any headache for me at all. > e.g. when one tries to do "create inst var accessors" for a class that one has > added a className inst var? Honestly, dude, THAT is what irritated you enough to want to delete this 17 year old method? A special-case of a special-case? I would rather get rid of "create inst var accessors" altogether, then you would not have that problem. :) I don't really see any problem with #className, and easily presenting the types of objects in a list is very feasible thing to want to do. -1 On Thu, Mar 23, 2017 at 4:08 PM, Eliot Miranda <[hidden email]> wrote: > Hi All, > > I find Object>>#className offensive; is methods are far nicer than this > nonsense. First of all className is implemented in several Monticello > classes to do what you'd expect; answer the name of a class of some > to-be-imported item such as a method or class definition. Second, there are > tests out there that simply don't do what a naive reading might expect: > > testClassCommentAnnotation > | annotation | > browser selectSystemCategory: browser class category. > browser selectClass: browser class. > annotation := browser annotationForClassCommentFor: browser class. > self assert: (annotation includesSubstring: browser class organization > commentStamp). > self assert: (annotation includesSubstring: 'class comment for'). > self assert: (annotation includesSubstring: browser className). > > Is it /really/ that hard to write foo class name instead of foo className > and have subclasses prevented from using it easily e.g. when one tries to do > "create inst var accessors" for a class that one has added a className inst > var? We already have Object>>#name, which is horrible enough. Ca we think > seriously about nuking Object>>#className? > > The grouch. > _,,,^..^,,,_ > best, Eliot > > > |
|
|
In reply to this post by Eliot Miranda-2
What I WOULD like to have, though, is an extra level of indirection
for everywhere in the system that sends #class. We have Object>>#xxxClass but I would like to rename it to something nicer like #actualClass before changing senders... On Thu, Mar 23, 2017 at 4:08 PM, Eliot Miranda <[hidden email]> wrote: > Hi All, > > I find Object>>#className offensive; is methods are far nicer than this > nonsense. First of all className is implemented in several Monticello > classes to do what you'd expect; answer the name of a class of some > to-be-imported item such as a method or class definition. Second, there are > tests out there that simply don't do what a naive reading might expect: > > testClassCommentAnnotation > | annotation | > browser selectSystemCategory: browser class category. > browser selectClass: browser class. > annotation := browser annotationForClassCommentFor: browser class. > self assert: (annotation includesSubstring: browser class organization > commentStamp). > self assert: (annotation includesSubstring: 'class comment for'). > self assert: (annotation includesSubstring: browser className). > > Is it /really/ that hard to write foo class name instead of foo className > and have subclasses prevented from using it easily e.g. when one tries to do > "create inst var accessors" for a class that one has added a className inst > var? We already have Object>>#name, which is horrible enough. Ca we think > seriously about nuking Object>>#className? > > The grouch. > _,,,^..^,,,_ > best, Eliot > > > |
|
|
In reply to this post by Chris Muller-3
> On 23-03-2017, at 3:10 PM, Chris Muller <[hidden email]> wrote: > > I would rather get rid of "create inst var accessors" altogether, then > you would not have that problem. :) If I could think of a way of getting away with it I’d make it completely impossible to make methods with the same name as an ivar. All it does is encourage the sort of scoundrels ( cads! bounders! mountebanks I tell you!) that treat classes as Pascal records or C structs. Didn’tortabealloweditellya. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Negligent (adj.), describes a condition in which you absentmindedly answer the door in your nightgown. |
|
|
In reply to this post by Eliot Miranda-2
> On 23-03-2017, at 2:08 PM, Eliot Miranda <[hidden email]> wrote: > > Hi All, > > I find Object>>#className offensive; Doesn’t the concept of a className var and method become a bit problematic with Environments? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Looks for the "Any" key. |
|
|
In reply to this post by timrowledge
> On 24.03.2017, at 01:17, tim Rowledge <[hidden email]> wrote: > > >> On 23-03-2017, at 3:10 PM, Chris Muller <[hidden email]> wrote: >> >> I would rather get rid of "create inst var accessors" altogether, then >> you would not have that problem. :) > > If I could think of a way of getting away with it I’d make it completely impossible to make methods with the same name as an ivar. All it does is encourage the sort of scoundrels ( cads! bounders! mountebanks I tell you!) that treat classes as Pascal records or C structs. Didn’tortabealloweditellya. > I'd rather have the opposite direction. All instvars should be required to have accessors; I don't want see any code that accesses instvars directly _execpt_ accessors… > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Negligent (adj.), describes a condition in which you absentmindedly answer the door in your nightgown. > > > |
|
|
On 3/24/17, Tobias Pape <[hidden email]> wrote:
> >> On 24.03.2017, at 01:17, tim Rowledge <[hidden email]> wrote: >> >> >>> On 23-03-2017, at 3:10 PM, Chris Muller <[hidden email]> wrote: >>> >>> I would rather get rid of "create inst var accessors" altogether, then >>> you would not have that problem. :) >> >> If I could think of a way of getting away with it I’d make it completely >> impossible to make methods with the same name as an ivar. All it does is >> encourage the sort of scoundrels ( cads! bounders! mountebanks I tell >> you!) that treat classes as Pascal records or C structs. >> Didn’tortabealloweditellya. >> > > I'd rather have the opposite direction. > All instvars should be required to have accessors; I don't want see any code > that accesses instvars directly _execpt_ accessors… > >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Negligent (adj.), describes a condition in which you absentmindedly answer >> the door in your nightgown. >> >> >> > > > |
|
|
In reply to this post by Tobias Pape
On Fri, 24 Mar 2017, Tobias Pape wrote:
> >> On 24.03.2017, at 01:17, tim Rowledge <[hidden email]> wrote: >> >> >>> On 23-03-2017, at 3:10 PM, Chris Muller <[hidden email]> wrote: >>> >>> I would rather get rid of "create inst var accessors" altogether, then >>> you would not have that problem. :) >> >> If I could think of a way of getting away with it I’d make it completely impossible to make methods with the same name as an ivar. All it does is encourage the sort of scoundrels ( cads! bounders! mountebanks I tell you!) that treat classes as Pascal records or C structs. Didn’tortabealloweditellya. >> > > I'd rather have the opposite direction. > All instvars should be required to have accessors; I don't want see any code that accesses instvars directly _execpt_ accessors… If it is a good idea, then what are instance variables good for? Levente > > >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Negligent (adj.), describes a condition in which you absentmindedly answer the door in your nightgown. >> >> >> |
|
|
In reply to this post by Chris Muller-3
Hi Chris,
On Thu, Mar 23, 2017 at 3:10 PM, Chris Muller <[hidden email]> wrote: Hi Eliot, You miss my point. Many people complain about the proliferation of 'is' methods, but I see them as well worth the cost. I agree that name is a travesty and className falls in the same category for me. The issue is it exists as a printing method but it - collides with methods that are used to model classes and there are plenty of them - doesn't provide much utility as it is effectively foo class name, and foo className saves one character.
Except when one uses "create inst var accessors" and the getter is not produced ;-)
Well, each to his own.
_,,,^..^,,,_ best, Eliot |
|
|
> On 24.03.2017, at 18:10, Eliot Miranda <[hidden email]> wrote: > > - doesn't provide much utility as it is effectively foo class name, and foo className saves one character. Law of Demeter. Best regards -Tobias |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
>> Object>>#name is a travesty, but #className seems perfectly >> reasonable. Did you notice the comment of the method? -- it has >> nothing to do with "is" testing, but for accessing the type names of >> objects for a list, useful for presenting a list classes which could be >> the receiver for constructor of more objects. > > You miss my point. Many people complain about the proliferation of 'is' > methods, but I see them as well worth the cost. I agree that name is a > travesty and className falls in the same category for me. The issue is it > exists as a printing method but it > - collides with methods that are used to model classes and there are plenty > of them As does every method on Object. Name overloading happens all the time. I don't think it should be a reason to single out any particular method for de-rezolution. :) > - doesn't provide much utility as it is effectively foo class name, and foo > className saves one character. The utility is that it provides a performable selector which, as alluded, can be used by list widgets or Maui. Real quick, just so you know, I'm not passtionate about this particular method, I'm just more interested in understanding and discussing our criteria for decisions. You mentioned utility, that is definitely one. Another is the human <-----> Class-Library interface. I capitalized Class-Library there to help think of it as a singular "Thing" that has its own big-picture aesthetic wholeness and completeness. It's not merely a collection of optimized classes and methods. >> I have overrides of #className in some of the Ma Serializer classes, >> it's never presented any headache for me at all. > > > Except when one uses "create inst var accessors" and the getter is not > produced ;-) Maybe that feature could be simply fixed to generate the overriding method anyway, and put it in an "overriding" category instead of "accessing", and/or add in a super call. I just think we should not let this minor kink in a rinky-dink IDE feature like "create inst var accesors" drive our decisions about the content and aesthetic and usability of The Class Library. Best Regards, Chris |
|
|
In reply to this post by Tobias Pape
On Fri, 24 Mar 2017, Tobias Pape wrote:
> >> On 24.03.2017, at 18:10, Eliot Miranda <[hidden email]> wrote: >> >> - doesn't provide much utility as it is effectively foo class name, and foo className saves one character. > > Law of Demeter. Blindly applying such ideas will result in a huge mess. In this case #className and #name cause more trouble than benefit. Object should shadow as few accessors as possible. Levente > > Best regards > -Tobias |
|
|
> On 24.03.2017, at 19:36, Levente Uzonyi <[hidden email]> wrote: > > On Fri, 24 Mar 2017, Tobias Pape wrote: > >> >>> On 24.03.2017, at 18:10, Eliot Miranda <[hidden email]> wrote: >>> - doesn't provide much utility as it is effectively foo class name, and foo className saves one character. >> >> Law of Demeter. > > Blindly applying such ideas will result in a huge mess. > In this case #className and #name cause more trouble than benefit. I still fail to see that for #className. > Object should shadow as few accessors as possible. > That's messy. How can we predict what superclass will shadow what in which subclass. That's not gonna work. How should in 2000 anyone anticipate that someone years later will create Monticello and name an instance variable 'className'. What about environment? executor? flash? presenter? scriptPerformer? Do we have to anticipate that somewhen in some domain implementation these could be accessors down the hierarchy? Best regards -Tobias > Levente > >> >> Best regards >> -Tobias > |
|
|
In reply to this post by Tobias Pape
> On 24-03-2017, at 12:56 AM, Tobias Pape <[hidden email]> wrote: > > All instvars should be required to have accessors; I don't want see any code that accesses instvars directly _execpt_ accessors… Well, there’s pro’s and con’s for that. Pro - nice regular feature; you always use a message and never an instvar reference (except some variety of magic to allow the one and only accessor to work) and then maybe you could remove all the ivar accessing bytecodes too. With a naive implementation you can do ^foo ifNil:[foo := MyClass makeFoo] type lazy initialisation easily. Obviously a little more involved if you go the Self route, but equally obviously, doable since they already did it. Con - almost certainly slower and particularly so for a version with a lazy init since that will always get checked. Potentially fixable with Sista tricks. - makes it far too easy and inviting to write truly appalling code. For example, how often do we see less experienced people write code that might as well be C? e.g. testval := (dog legs first paw claws) at: 2. testval type = #cutRecently ifTrue:[ ((dog legs first paw claws) at: 2) type: #buffedAndPolished]. Which is an example of massive violation of encapsulation, dreadful design integrity, poor maintainability, and general awfulness. Worse, it’s a very common pattern. Now certainly simply having ivar accessors is not the sole and complete cause of such horrors but it certainly makes it very inviting. If - big if - we could make such accessors actually private then there might be a better argument for them. I’m sure we could come up with something that might work if we really want to; in fact how about this rough concept (which I dare say is already extant in someone’s PhD thesis somewhen) Use of ivar name in code is treated as now - it access that object within ‘self’ BUT if the value is nil it diverts (like ifTrue: does for non-booleans) to a method named something vaguely intuitable like #initialiseIVar{name}. If no such method exists then the accessor is as before - with obvious costs similar to cache-flushing any time one is added or deleted or otherwise relevantly changed. This would keep the ivar name a private thing to the class (just as now) unless someone specifically wanted to provide it as a public accessor. Writing code that refers to iVar would work exactly as now. Adding #initialiseIVar would cause recompiling of all methods using the applicable bytecode(s) to use some other bytecode(s) that test and send #initialiseIVar when required. Deleting it would do the obvious. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim The problem with the gene pool is that there is no lifeguard. |
|
|
In reply to this post by Tobias Pape
On Fri, 24 Mar 2017, Tobias Pape wrote:
> >> On 24.03.2017, at 19:36, Levente Uzonyi <[hidden email]> wrote: >> >> On Fri, 24 Mar 2017, Tobias Pape wrote: >> >>> >>>> On 24.03.2017, at 18:10, Eliot Miranda <[hidden email]> wrote: >>>> - doesn't provide much utility as it is effectively foo class name, and foo className saves one character. >>> >>> Law of Demeter. >> >> Blindly applying such ideas will result in a huge mess. >> In this case #className and #name cause more trouble than benefit. > > I still fail to see that for #className. > >> Object should shadow as few accessors as possible. >> > > That's messy. How can we predict what superclass will shadow what in which subclass. > That's not gonna work. How should in 2000 anyone anticipate that someone years later will create Monticello and name an instance variable 'className'. > > What about environment? executor? flash? presenter? scriptPerformer? You act as if I were to support the presence of any of those methods; quite the contrary. > Do we have to anticipate that somewhen in some domain implementation these could be accessors down the hierarchy? You can't see the future, but you can think twice _before_ adding a selector understood by _all objects_ in the system. Were there a huge warning displayed whenever you attempted to do that, there would probably be way fewer methods like those you listed. Levente P.S.: The whole macpal category of Object should be cleaned up. > > Best regards > -Tobias > > >> Levente >> >>> >>> Best regards >>> -Tobias >> |
|
|
> On 24.03.2017, at 22:44, Levente Uzonyi <[hidden email]> wrote: > > On Fri, 24 Mar 2017, Tobias Pape wrote: > >> >>> On 24.03.2017, at 19:36, Levente Uzonyi <[hidden email]> wrote: >>> On Fri, 24 Mar 2017, Tobias Pape wrote: >>>>> On 24.03.2017, at 18:10, Eliot Miranda <[hidden email]> wrote: >>>>> - doesn't provide much utility as it is effectively foo class name, and foo className saves one character. >>>> Law of Demeter. >>> Blindly applying such ideas will result in a huge mess. >>> In this case #className and #name cause more trouble than benefit. >> >> I still fail to see that for #className. >> >>> Object should shadow as few accessors as possible. >> >> That's messy. How can we predict what superclass will shadow what in which subclass. >> That's not gonna work. How should in 2000 anyone anticipate that someone years later will create Monticello and name an instance variable 'className'. >> >> What about environment? executor? flash? presenter? scriptPerformer? > > You act as if I were to support the presence of any of those methods; quite the contrary. > No, I'm saying putting the burden of knowing the future on the methods in Object is unreasonable. And I think it is perfectly ok to have different meanings to the same method between the root of our hierarchy and other classes. Otherwise we could always use ProtoObject. >> Do we have to anticipate that somewhen in some domain implementation these could be accessors down the hierarchy? > > You can't see the future, but you can think twice _before_ adding a selector understood by _all objects_ in the system. > Were there a huge warning displayed whenever you attempted to do that, there would probably be way fewer methods like those you listed. I don't know. Maybe the problem here is that we still don't have a good modu… ok I stop here. > > Levente > > P.S.: The whole macpal category of Object should be cleaned up. what is mapcal after all? and btw, who is 'sw'? > >> >> Best regards >> -Tobias >> >> >>> Levente >>>> Best regards >>>> -Tobias |
|
|
In reply to this post by timrowledge
Another con is that it makes it harder, sometimes way harder, to find
references to a given variable. Levente On Fri, 24 Mar 2017, tim Rowledge wrote: > >> On 24-03-2017, at 12:56 AM, Tobias Pape <[hidden email]> wrote: >> >> All instvars should be required to have accessors; I don't want see any code that accesses instvars directly _execpt_ accessors… > > Well, there’s pro’s and con’s for that. > > Pro > - nice regular feature; you always use a message and never an instvar reference (except some variety of magic to allow the one and only accessor to work) and then maybe you could remove all the ivar accessing bytecodes too. With a naive implementation you can do > ^foo ifNil:[foo := MyClass makeFoo] > type lazy initialisation easily. Obviously a little more involved if you go the Self route, but equally obviously, doable since they already did it. > > Con > - almost certainly slower and particularly so for a version with a lazy init since that will always get checked. Potentially fixable with Sista tricks. > - makes it far too easy and inviting to write truly appalling code. For example, how often do we see less experienced people write code that might as well be C? > e.g. > testval := (dog legs first paw claws) at: 2. > testval type = #cutRecently ifTrue:[ ((dog legs first paw claws) at: 2) type: #buffedAndPolished]. > > Which is an example of massive violation of encapsulation, dreadful design integrity, poor maintainability, and general awfulness. Worse, it’s a very common pattern. > > Now certainly simply having ivar accessors is not the sole and complete cause of such horrors but it certainly makes it very inviting. If - big if - we could make such accessors actually private then there might be a better argument for them. > > I’m sure we could come up with something that might work if we really want to; in fact how about this rough concept (which I dare say is already extant in someone’s PhD thesis somewhen) > > Use of ivar name in code is treated as now - it access that object within ‘self’ BUT if the value is nil it diverts (like ifTrue: does for non-booleans) to a method named something vaguely intuitable like #initialiseIVar{name}. If no such method exists then the accessor is as before - with obvious costs similar to cache-flushing any time one is added or deleted or otherwise relevantly changed. > > This would keep the ivar name a private thing to the class (just as now) unless someone specifically wanted to provide it as a public accessor. Writing code that refers to iVar would work exactly as now. Adding #initialiseIVar would cause recompiling of all methods using the applicable bytecode(s) to use some other bytecode(s) that test and send #initialiseIVar when required. Deleting it would do the obvious. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > The problem with the gene pool is that there is no lifeguard. |
|
|
In reply to this post by Tobias Pape
On Fri, Mar 24, 2017 at 2:49 PM, Tobias Pape <[hidden email]> wrote: > what is mapcal after all? and btw, who is 'sw'? sw is none other than Scott Wallace, of course. As far as I know, MacPal was an experimental end-user programming environment, and if I'm not mistaken, it was conceived and worked on a bit before Squeak got started. I think Scott and co. were using Squeak to further advance the idea. This is an informative page I diid not know: I am pretty sure that we had the paper of MacPal (and one on Constructo) somewhere at our office, but cannot find it... -- Yoshiki
|
|
|
> On 24.03.2017, at 23:19, Yoshiki Ohshima <[hidden email]> wrote: > > > > On Fri, Mar 24, 2017 at 2:49 PM, Tobias Pape <[hidden email]> wrote: > > > > P.S.: The whole macpal category of Object should be cleaned up. > what is mapcal after all? and btw, who is 'sw'? > > sw is none other than Scott Wallace, of course. As far as I know, MacPal was an experimental end-user programming environment, and if I'm not mistaken, it was conceived and worked on a bit before Squeak got started. I think Scott and co. were using Squeak to further advance the idea. > > This is an informative page I diid not know: > > http://homepages.cwi.nl/~steven/sigchi/bulletin/1998.2/spohrer.html > > I am pretty sure that we had the paper of MacPal (and one on Constructo) somewhere at our office, but cannot find it... Ohh that's pretty interesting, thanks for sharing, Yoshiki! Best regards -Tobias |
|
|
On Fri, Mar 24, 2017 at 3:27 PM, Tobias Pape <[hidden email]> wrote:
For SK8 and some other ATG stuff, I have some movies that are digitized from VHS and other kind of tapes. I'd still hesitate to make all of those public, but there are some already visible on my YouTube channel. -- Yoshiki
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |