why are Help topics in the meta-side
All help topics (subclasses of CustomHelp) have all the content on the class-side. This seems very weird to me, because the class-side should about managing the meta, not containing the content itself. It feels weird. Peter
This is as if you would ask why are specs on the class side? You may actually see Help information as 'meta information'. It is information about .... The content is only needed once per topic. No different instances of the same topic. --Hannes On 10/3/17, Peter Uhnák <i.uhnak@gmail.com> wrote:
All help topics (subclasses of CustomHelp) have all the content on the class-side.
This seems very weird to me, because the class-side should about managing the meta, not containing the content itself.
It feels weird.
Peter
On Tue, Oct 3, 2017 at 2:17 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
This is as if you would ask
why are specs on the class side?
I can certainly ask that, and there's in fact no reason why it would have to be there (because when the layout is being retrieved, the instance is already available).
You may actually see Help information as 'meta information'. It is information about ....
If you put it on the class-side of the class that it is about then I would agree. But that is not the case here. The object is the content, not about the content.
The content is only needed once per topic. No different instances of the same topic.
This is not actually true; the topic is instantiated anew for every help browser opened (and every time browser is opened). And in fact the CustomHelp subclass is recasted to HelpTopic at runtime, which makes the entire class quite pointless; which is what I don't understand. Peter
The information for a help topic on the class side is used to create a help instance. Even if I technically create several instances of a particular help topic with information taken from the class side conceptually I have only _one_ help topic. The instances all share exactly the same content. Maybe the idea of 'Uniclass' (Etoys / Squeak') though not exactly the same may help. "UniClasses are classes for the instance specific behavior of just one instance." http://wiki.squeak.org/squeak/2402 In Smalltalk I always have to deal with classes. A class is an object as well. Good to keep information for cases where I do not care to have different instances with different state. HTH Hannes On 10/3/17, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Tue, Oct 3, 2017 at 2:17 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
This is as if you would ask
why are specs on the class side?
I can certainly ask that, and there's in fact no reason why it would have to be there (because when the layout is being retrieved, the instance is already available).
You may actually see Help information as 'meta information'. It is information about ....
If you put it on the class-side of the class that it is about then I would agree. But that is not the case here. The object is the content, not about the content.
The content is only needed once per topic. No different instances of the same topic.
This is not actually true; the topic is instantiated anew for every help browser opened (and every time browser is opened).
And in fact the CustomHelp subclass is recasted to HelpTopic at runtime, which makes the entire class quite pointless; which is what I don't understand.
Peter
In the end it is probably a matter of conventions. Instruction how to construct something (e.g. Spec) / configuration information / descriptions / help information / examples are kept on the class side. HH On 10/3/17, H. Hirzel <hannes.hirzel@gmail.com> wrote:
The information for a help topic on the class side is used to create a help instance.
Even if I technically create several instances of a particular help topic with information taken from the class side conceptually I have only _one_ help topic. The instances all share exactly the same content.
Maybe the idea of 'Uniclass' (Etoys / Squeak') though not exactly the same may help. "UniClasses are classes for the instance specific behavior of just one instance." http://wiki.squeak.org/squeak/2402
In Smalltalk I always have to deal with classes. A class is an object as well. Good to keep information for cases where I do not care to have different instances with different state.
HTH
Hannes
On 10/3/17, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Tue, Oct 3, 2017 at 2:17 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
This is as if you would ask
why are specs on the class side?
I can certainly ask that, and there's in fact no reason why it would have to be there (because when the layout is being retrieved, the instance is already available).
You may actually see Help information as 'meta information'. It is information about ....
If you put it on the class-side of the class that it is about then I would agree. But that is not the case here. The object is the content, not about the content.
The content is only needed once per topic. No different instances of the same topic.
This is not actually true; the topic is instantiated anew for every help browser opened (and every time browser is opened).
And in fact the CustomHelp subclass is recasted to HelpTopic at runtime, which makes the entire class quite pointless; which is what I don't understand.
Peter
2017-10-03 10:14 GMT-03:00 H. Hirzel <hannes.hirzel@gmail.com>:
In the end it is probably a matter of conventions.
Instruction how to construct something (e.g. Spec)
Conventions and history, which maybe are the same thing :) VisualSmalltalk/VisualWorks, Dolphin, VAST keep the definition of the windows/panes in the class side, whether they're Smalltalk expressions or binary/literal arrays (Dolphin). In the case of Dolphin each "class method" defines a "resource" you can have more than one layout for the same class, so you can have a "read only" view (resource) and an "editable" view sharing the same instance behavior. Also, having it class side you can reference it/preview (rendered) from other views without having to instantiate them, which might require having a valid model, etc.
/ configuration information / descriptions / help information / examples are kept on the class side.
In fact I don't like that Magritte moved the descriptions from class to instance side. My two cents on this. Regards! Esteban A. Maringolo
participants (3)
-
Esteban A. Maringolo -
H. Hirzel -
Peter Uhnák