Naming of Global Session
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract. IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much. Any comments? T.
It seems that Pharo 3.0 had a tendency to switch to abstract names instead for that sort of concept... 2.0 OSPlatform platformName -> 3.0 Smalltalk os name 2.0 vmVersion -> 3.0 Smalltalk vm version To keep with that, I'd say that Session isn't to be used directly, but we can access it via: Smalltalk vm session or Smalltalk session (and, if we can access the external user session, we may also use "tentatively" Smalltalk os session!). It can then stay as Session, ImageSession or whatever. Thierry Le 12/09/2013 13:11, Torsten Bergmann a écrit :
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
+1 Very abstract names are fine when you have namespaces, otherwise I rather chose more specific names. Regards! Esteban A. Maringolo 2013/9/12 Torsten Bergmann <astares@gmx.de>
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
+1 too. Session is a bad name for a class. More than that, the people who introduced it, didn't care about: - removing unused session ivar from SmalltalkImage class - that putting #reset in Session class side, means exposing resetting mechanism to public, instead of keeping it private (and it is quite important to keep it private, because session should be reset once and only once and only in single , fully controllable place) from that perspective, i'd prefer using 'session' ivar in SmalltalkImage instead of 'current' in Session. On 12 September 2013 15:13, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
+1
Very abstract names are fine when you have namespaces, otherwise I rather chose more specific names.
Regards!
Esteban A. Maringolo
2013/9/12 Torsten Bergmann <astares@gmx.de>
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
-- Best regards, Igor Stasenko.
Even more, it feels like we introducing another global (so users can write 'Session current' , but why not just 'Session' then?) and so a step backwards as to me. Because we trying to get rid of all those Display, World, InputSensor , ActiveHande etc globals for years. And last thing: there should be only one way to get current session object. now there's two: Smalltalk session and Session current and so, users now will inevitably raise the question: what is the right 'true' API for accessing it? and inevitably we will have two fighting camps, if we leave this thing in image and be used in various projects. On 13 September 2013 01:33, Igor Stasenko <siguctua@gmail.com> wrote:
+1 too. Session is a bad name for a class. More than that, the people who introduced it, didn't care about: - removing unused session ivar from SmalltalkImage class - that putting #reset in Session class side, means exposing resetting mechanism to public, instead of keeping it private (and it is quite important to keep it private, because session should be reset once and only once and only in single , fully controllable place)
from that perspective, i'd prefer using 'session' ivar in SmalltalkImage instead of 'current' in Session.
On 12 September 2013 15:13, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
+1
Very abstract names are fine when you have namespaces, otherwise I rather chose more specific names.
Regards!
Esteban A. Maringolo
2013/9/12 Torsten Bergmann <astares@gmx.de>
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Session is a class, not an instance that is a BIG difference. The same goes for VirtualMachine, OSPlatform, OSEnvironment etc. These are all classes, but you only work with their instances: OSPlatform current == Smalltalk os VirtualMachine current == Smalltalk vm OSEnvironment current == Smalltalk os environment and thus, it is quite natural to deduce Session current == Smalltalk session it's all symmetric, not strange objects that have names like classes but are actually instances. On 2013-09-12, at 20:51, Igor Stasenko <siguctua@gmail.com> wrote:
Even more, it feels like we introducing another global (so users can write 'Session current' , but why not just 'Session' then?) and so a step backwards as to me. Because we trying to get rid of all those Display, World, InputSensor , ActiveHande etc globals for years.
And last thing: there should be only one way to get current session object. now there's two: Smalltalk session and Session current
and so, users now will inevitably raise the question: what is the right 'true' API for accessing it? and inevitably we will have two fighting camps, if we leave this thing in image and be used in various projects.
On 13 September 2013 01:33, Igor Stasenko <siguctua@gmail.com> wrote:
+1 too. Session is a bad name for a class. More than that, the people who introduced it, didn't care about: - removing unused session ivar from SmalltalkImage class - that putting #reset in Session class side, means exposing resetting mechanism to public, instead of keeping it private (and it is quite important to keep it private, because session should be reset once and only once and only in single , fully controllable place)
from that perspective, i'd prefer using 'session' ivar in SmalltalkImage instead of 'current' in Session.
On 12 September 2013 15:13, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
+1
Very abstract names are fine when you have namespaces, otherwise I rather chose more specific names.
Regards!
Esteban A. Maringolo
2013/9/12 Torsten Bergmann <astares@gmx.de>
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 13 September 2013 02:06, Camillo Bruni <camillobruni@gmail.com> wrote:
Session is a class, not an instance that is a BIG difference. The same goes for VirtualMachine, OSPlatform, OSEnvironment etc. These are all classes, but you only work with their instances:
OSPlatform current == Smalltalk os VirtualMachine current == Smalltalk vm OSEnvironment current == Smalltalk os environment
and thus, it is quite natural to deduce
Session current == Smalltalk session
it's all symmetric, not strange objects that have names like classes but are actually instances.
That's not the kind of symmetry i would like to see :) It doesn't hurts to have 2 ways to do the same thing (Perl even armed this 'as a good thing' btw), but to my taste there should be only one way, which frees me (as a user) from unnecessary doubts and need to search for vague explanations from system's authors.
On 2013-09-12, at 20:51, Igor Stasenko <siguctua@gmail.com> wrote:
Even more, it feels like we introducing another global (so users can write 'Session current' , but why not just 'Session' then?) and so a step backwards as to me. Because we trying to get rid of all those Display, World, InputSensor , ActiveHande etc globals for years.
And last thing: there should be only one way to get current session object. now there's two: Smalltalk session and Session current
and so, users now will inevitably raise the question: what is the right 'true' API for accessing it? and inevitably we will have two fighting camps, if we leave this thing in image and be used in various projects.
-- Best regards, Igor Stasenko.
On 2013-09-16, at 05:25, Igor Stasenko <siguctua@gmail.com> wrote:
On 13 September 2013 02:06, Camillo Bruni <camillobruni@gmail.com> wrote:
Session is a class, not an instance that is a BIG difference. The same goes for VirtualMachine, OSPlatform, OSEnvironment etc. These are all classes, but you only work with their instances:
OSPlatform current == Smalltalk os VirtualMachine current == Smalltalk vm OSEnvironment current == Smalltalk os environment
and thus, it is quite natural to deduce
Session current == Smalltalk session
it's all symmetric, not strange objects that have names like classes but are actually instances.
That's not the kind of symmetry i would like to see :) It doesn't hurts to have 2 ways to do the same thing (Perl even armed this 'as a good thing' btw), but to my taste there should be only one way, which frees me (as a user) from unnecessary doubts and need to search for vague explanations from system's authors.
That's the moment where you add a custom lint rule to verify that the user actually does the right thing. Damien Cassou recently added something like that to no longer access the ui manager directly via it's class.
so could you do another iteration on it. Stef On Sep 13, 2013, at 1:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Even more, it feels like we introducing another global (so users can write 'Session current' , but why not just 'Session' then?) and so a step backwards as to me. Because we trying to get rid of all those Display, World, InputSensor , ActiveHande etc globals for years.
And last thing: there should be only one way to get current session object. now there's two: Smalltalk session and Session current
and so, users now will inevitably raise the question: what is the right 'true' API for accessing it? and inevitably we will have two fighting camps, if we leave this thing in image and be used in various projects.
On 13 September 2013 01:33, Igor Stasenko <siguctua@gmail.com> wrote: +1 too. Session is a bad name for a class. More than that, the people who introduced it, didn't care about: - removing unused session ivar from SmalltalkImage class - that putting #reset in Session class side, means exposing resetting mechanism to public, instead of keeping it private (and it is quite important to keep it private, because session should be reset once and only once and only in single , fully controllable place)
from that perspective, i'd prefer using 'session' ivar in SmalltalkImage instead of 'current' in Session.
On 12 September 2013 15:13, Esteban A. Maringolo <emaringolo@gmail.com> wrote: +1
Very abstract names are fine when you have namespaces, otherwise I rather chose more specific names.
Regards!
Esteban A. Maringolo
2013/9/12 Torsten Bergmann <astares@gmx.de> In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class? That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)? On Fri, Sep 13, 2013 at 12:15 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
so could you do another iteration on it.
Stef
On Sep 13, 2013, at 1:51 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Even more, it feels like we introducing another global (so users can write 'Session current' , but why not just 'Session' then?) and so a step backwards as to me. Because we trying to get rid of all those Display, World, InputSensor , ActiveHande etc globals for years.
And last thing: there should be only one way to get current session object. now there's two: Smalltalk session and Session current
and so, users now will inevitably raise the question: what is the right 'true' API for accessing it? and inevitably we will have two fighting camps, if we leave this thing in image and be used in various projects.
On 13 September 2013 01:33, Igor Stasenko <siguctua@gmail.com> wrote:
+1 too. Session is a bad name for a class. More than that, the people who introduced it, didn't care about: - removing unused session ivar from SmalltalkImage class - that putting #reset in Session class side, means exposing resetting mechanism to public, instead of keeping it private (and it is quite important to keep it private, because session should be reset once and only once and only in single , fully controllable place)
from that perspective, i'd prefer using 'session' ivar in SmalltalkImage instead of 'current' in Session.
On 12 September 2013 15:13, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
+1
Very abstract names are fine when you have namespaces, otherwise I rather chose more specific names.
Regards!
Esteban A. Maringolo
2013/9/12 Torsten Bergmann <astares@gmx.de>
In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract.
IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much.
Any comments? T.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 2013-09-13, at 12:09, Chris Cunningham <cunningham.cb@gmail.com> wrote:
so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class?
I would say so. It is as generic as the name suggests. The class is lightweight and only contains the time when it was created.
That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)?
It is a normal class, thus yes, collision is possible. Again, it can easily serve as a superclass for other session-like objects.
i would like session to support a cache. something like either: Smalltalk session at: x ifAbsentPut: [ y ] or Smalltalk session cacheAt: x ifAbsentPut: [ y ] On 13 September 2013 17:27, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-09-13, at 12:09, Chris Cunningham <cunningham.cb@gmail.com> wrote:
so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class?
I would say so. It is as generic as the name suggests. The class is lightweight and only contains the time when it was created.
That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)?
It is a normal class, thus yes, collision is possible. Again, it can easily serve as a superclass for other session-like objects.
-- Best regards, Igor Stasenko.
sure, go ahead. On 2013-09-16, at 05:13, Igor Stasenko <siguctua@gmail.com> wrote:
i would like session to support a cache. something like either: Smalltalk session at: x ifAbsentPut: [ y ] or Smalltalk session cacheAt: x ifAbsentPut: [ y ]
On 13 September 2013 17:27, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-09-13, at 12:09, Chris Cunningham <cunningham.cb@gmail.com> wrote:
so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class?
I would say so. It is as generic as the name suggests. The class is lightweight and only contains the time when it was created.
That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)?
It is a normal class, thus yes, collision is possible. Again, it can easily serve as a superclass for other session-like objects.
-- Best regards, Igor Stasenko.
What would you put in that cache? Esteban A. Maringolo 2013/9/16 Camillo Bruni <camillobruni@gmail.com>:
sure, go ahead.
On 2013-09-16, at 05:13, Igor Stasenko <siguctua@gmail.com> wrote:
i would like session to support a cache. something like either: Smalltalk session at: x ifAbsentPut: [ y ] or Smalltalk session cacheAt: x ifAbsentPut: [ y ]
On 13 September 2013 17:27, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-09-13, at 12:09, Chris Cunningham <cunningham.cb@gmail.com> wrote:
so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class?
I would say so. It is as generic as the name suggests. The class is lightweight and only contains the time when it was created.
That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)?
It is a normal class, thus yes, collision is possible. Again, it can easily serve as a superclass for other session-like objects.
-- Best regards, Igor Stasenko.
On 13 September 2013 17:27, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-09-13, at 12:09, Chris Cunningham <cunningham.cb@gmail.com> wrote:
so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class?
I would say so. It is as generic as the name suggests. The class is lightweight and only contains the time when it was created.
That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)?
It is a normal class, thus yes, collision is possible. Again, it can easily serve as a superclass for other session-like objects.
i doubt it can serve as a basis, because it is not abstract. Its implementation collides just from a beginning , if you need to have multiple session(s) of same kind per connection to some service, because it uses singleton pattern. Take seaside, for example, it uses separate session per each connection. -- Best regards, Igor Stasenko.
participants (7)
-
Camillo Bruni -
Chris Cunningham -
Esteban A. Maringolo -
Goubier Thierry -
Igor Stasenko -
Stéphane Ducasse -
Torsten Bergmann