[Pharo-project] hasPoolVarNamed: semantics :(
Hi guys Class>>hasPoolVarNamed: aString "Return whether the receiver has a pool variable named: aString" self hasSharedPools ifTrue: [ self sharedPools do: [:each | (each usesClassVarNamed: aString) ifTrue: [ ^true ]]] ifFalse: [ ^false ]. ^false So this means to me that a subclass of a shared pools user does not inherit the fact that its superclass effectively use a sharedPool. I would prefer that this would be the inverse. self assert: (RootClassPoolUser hasPoolVarNamed: 'Author'). "a subclass " self assert: (SubclassPoolUser hasPoolVarNamed: 'Author'). What do you think? may be we should rename it hasLocalPoolvarNamed: especially since we have usesPoolVarNamed: which takes into account the hierarchy only when the class starts to use a shared pool (oh boy) and is bogus (I wrote probably that code of course without tests. Now I have them.). Class>>usesPoolVarNamed: aString "Return whether the receiver has a pool variable named: aString" self hasSharedPools ifTrue: [ self allSharedPools do: [:each | (each usesClassVarNamed: aString) ifTrue: [^true]]] ifFalse: [^false]. ^false I wrote it now with tests as follows: Class>>usesPoolVarNamed: aString "Return whether the receiver has a pool variable named: aString" self allSharedPools do: [:each | (each usesClassVarNamed: aString) ifTrue: [^true]]. ^ false Stef
Stéphane Ducasse wrote
What do you think? may be we should rename it hasLocalPoolvarNamed:
That sounds clearer. #has vs. #uses is more subtle and potentially confusing. -- View this message in context: http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I just came back to eater after 7 hours of train http://code.google.com/p/pharo/issues/detail?id=5101 On Dec 13, 2011, at 10:33 PM, Sean P. DeNigris wrote:
Stéphane Ducasse wrote
What do you think? may be we should rename it hasLocalPoolvarNamed:
That sounds clearer. #has vs. #uses is more subtle and potentially confusing.
-- View this message in context: http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
2011/12/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I just came back to eater after 7 hours of train
    http://code.google.com/p/pharo/issues/detail?id=5101
Ah yes, you probably wrote original code after 15h of airplane and 8h time difference ;) I wonder if SharedPool were inherited in original st-80 ? Nicolas
On Dec 13, 2011, at 10:33 PM, Sean P. DeNigris wrote:
Stéphane Ducasse wrote
What do you think? may be we should rename it    hasLocalPoolvarNamed:
That sounds clearer. #has vs. #uses is more subtle and potentially confusing.
-- View this message in context: http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Dec 13, 2011 at 2:04 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/12/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I just came back to eater after 7 hours of train
Ah yes, you probably wrote original code after 15h of airplane and 8h time difference ;)
I wonder if SharedPool were inherited in original st-80 ?
Yes. But IIRC SharedPools were *not* inherited in pre-Namespace VisualWorks, and they don't exist in Namespaced VW. Here's the class variable lookup method in Smalltalk-80 V2: Behavior>scopeHas: varName ifTrue: assocBlock "Look up varName in this class, its superclasses, and Smalltalk. If it is there, pass the association to assocBlock, and answer true; else answer false." | assoc | self withAllSuperclasses do: [:sup | (sup poolHas: varName ifTrue: assocBlock) ifTrue: [^true]]. assoc _ Smalltalk associationAt: varName ifAbsent: []. assoc == nil ifFalse: [assocBlock value: assoc. ^true]. ^false
Nicolas
On Dec 13, 2011, at 10:33 PM, Sean P. DeNigris wrote:
Stéphane Ducasse wrote
What do you think? may be we should rename it hasLocalPoolvarNamed:
That sounds clearer. #has vs. #uses is more subtle and potentially confusing.
-- View this message in context:
http://forum.world.st/hasPoolVarNamed-semantics-tp4191675p4192155.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- best, Eliot
Stephane, remember we changed a name lookup for classes not long ago. IIRC we changed the #bindingOf: So, i think that #sharedPools should answer a list of all pools of all classes in inheritance chain, which can be implemented like: sharedPools ^ superclass ifNil: [ self localSharedPools ] ifNotNil: [ self localSharedPools , superclass sharedPools ] note, that order (self localSharedPools , superclass sharedPools) are important, because pool in a subclass can shadow a pool variable defined in superclass. -- Best regards, Igor Stasenko.
On Dec 14, 2011, at 2:34 AM, Igor Stasenko wrote:
Stephane, remember we changed a name lookup for classes not long ago. IIRC we changed the #bindingOf: So, i think that #sharedPools should answer a list of all pools of all classes in inheritance chain, which can be implemented like:
sharedPools
^ superclass ifNil: [ self localSharedPools ] ifNotNil: [ self localSharedPools , superclass sharedPools ]
note, that order (self localSharedPools , superclass sharedPools) are important, because pool in a subclass can shadow a pool variable defined in superclass.
Exactly :) This is what usesVarPoolNamed: is doing. Stef
-- Best regards, Igor Stasenko.
On Wed, Dec 14, 2011 at 2:34 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Stephane, remember we changed a name lookup for classes not long ago. IIRC we changed the #bindingOf: So, i think that #sharedPools should answer a list of all pools of all classes in inheritance chain, which can be implemented like:
sharedPools
^ superclass ifNil: [ self localSharedPools ] ifNotNil: [ self localSharedPools , superclass sharedPools ]
mmmmmmm if you follow must of the existing methods similar to this one, I would understand that #sharedPools answers ONLY the localSharedPools and I would undertand there is a message #allSharedPools which answer what you are saying.
note, that order (self localSharedPools , superclass sharedPools) are important, because pool in a subclass can shadow a pool variable defined in superclass.
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
On Dec 13, 2011, at 11:04 PM, Nicolas Cellier wrote:
2011/12/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I just came back to eater after 7 hours of train
Ah yes, you probably wrote original code after 15h of airplane and 8h time difference ;)
I wonder if SharedPool were inherited in original st-80 ?
They should else you can have really crazy side effects and break the idea that a subclass is an extension of its superclass. In 1.4 we fixed their lookup already. Stef
participants (7)
-
Eliot Miranda -
Igor Stasenko -
Mariano Martinez Peck -
Nicolas Cellier -
Sean P. DeNigris -
Stéphane Ducasse -
Stéphane Ducasse