8 Jan
2007
8 Jan
'07
7:50 p.m.
Is anyone using Pragmas in 3.9 to do Magritte descriptions? If so, are
there any samples anywhere?
Ramon Leon
http://onsmalltalk.com
8 Jan
8 Jan
8:32 p.m.
not that I know but indeed this would be great :)
Lukas was planning to do something along this path.
At least we should learn if they scale for complex description.
stef
On 8 janv. 07, at 19:50, Ramon Leon wrote:
Is anyone using Pragmas in 3.9 to do Magritte
descriptions? If so,
are
there any samples anywhere?
Ramon Leon
http://onsmalltalk.com
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
9:12 p.m.
Ramon Leon a écrit :
Is anyone using Pragmas in 3.9 to do Magritte
descriptions? If so, are
there any samples anywhere?
What do you mean "using pragmas" ? Can you give us a simple example please ?
Do you mean a pragma to avoid starting method names by "description" ? I
don't think so but it should be easily done if not already.
9:18 p.m.
On 8 janv. 07, at 21:12, Damien Cassou wrote:
Ramon Leon a écrit :
<description: isDone type: Boolean>
Is anyone using Pragmas in 3.9 to do Magritte
descriptions? If
so, are
there any samples anywhere?
What do you mean "using pragmas" ? Can you give us a simple example
please ?
Do you mean a pragma to avoid starting method names by "description" ?
yeap
I
don't think so but it should be easily done if not already.
9:41 p.m.
Is anyone using Pragmas in 3.9 to do Magritte
descriptions? If so,
are
there any samples anywhere?
Yes, it is doable and there was an implementation some time ago in
the Magritte-Model package. The class was called MAPragmaBuilder a
subclass of MADescriptionBuilder.
- The reason that there were no examples was because code using
Pragmas cannot be loaded into 3.7 and 3.8 images, and we still have a
few of those that work with the latest version of Magritte. I know
that others are using Magritte with older Squeak versions as well.
- Therefor I removed MAPragmaBuilder from Magritte-Model, in one of
the latest cleaning efforts as it was never used ... now that you
ask, it might have been the wrong decision. You can reload it by
browsing the code of Magritte-Model-lr.228 and load the class. To
activate it you need to evaluate:
MADescriptionBuilder default: MAPragmaBuilder new
Then you can put your descriptions in a method like:
Address class>>street
<description>
^ MAStringDescription selector: #street
You can use class extensions to extend existing descriptions from a
different package:
Address class>>streetAddendum: aDescription
<description: #street>
^ aDescription beReadonly
It doesn't matter much for speed. And this implementation is
conceptually very close to the naming convention.
PS: I think it would be better to actually put the descriptions into
accessors (move them to to instance-side), but this means to change a
few others things and I didn't find the time to do that yet.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
10:11 p.m.
2007/1/8, Lukas Renggli <renggli(a)iam.unibe.ch>ch>:
Well I actually have a package that uses Magritte and will only load
into 3.9 because it uses Traits [1] so I'd be definitely interesed in
this. The only requirement I have is that it must play nice along with
the old way for legacy applications such as Pier ;)
[1] http://mc.lukas-renggli.ch/audioscrobbler.html
Cheers
Philippe
Is anyone
using Pragmas in 3.9 to do Magritte descriptions? If so,
are
there any samples anywhere?
Yes, it is doable and there was an implementation some time ago in
the Magritte-Model package. The class was called MAPragmaBuilder a
subclass of MADescriptionBuilder.
- The reason that there were no examples was because code using
Pragmas cannot be loaded into 3.7 and 3.8 images, and we still have a
few of those that work with the latest version of Magritte. I know
that others are using Magritte with older Squeak versions as well.
- Therefor I removed MAPragmaBuilder from Magritte-Model, in one of
the latest cleaning efforts as it was never used ... now that you
ask, it might have been the wrong decision. You can reload it by
browsing the code of Magritte-Model-lr.228 and load the class. To
activate it you need to evaluate:
MADescriptionBuilder default: MAPragmaBuilder new
Then you can put your descriptions in a method like:
Address class>>street
<description>
^ MAStringDescription selector: #street
You can use class extensions to extend existing descriptions from a
different package:
Address class>>streetAddendum: aDescription
<description: #street>
^ aDescription beReadonly
It doesn't matter much for speed. And this implementation is
conceptually very close to the naming convention.
PS: I think it would be better to actually put the descriptions into
accessors (move them to to instance-side), but this means to change a
few others things and I didn't find the time to do that yet.
10:55 p.m.
Then you can put your descriptions in a method like:
Address class>>street
<description>
^ MAStringDescription selector: #street
Cheers,
Lukas
Oh... You're just trying to avoid the description naming pattern, I see. I
was thinking something more along the lines of something on the accessors
directly...
Post>>author
<description: #SingleOption label: 'Author'>
<options: #findAuthors>
<relatedTo: #SBAuthor>
<displayField: #asString>
<required: true>
^author
Post>>comments
<description: #ToManyRelation label: 'Comments'>
<relatedTo: #Comment>
^comments
Post>>title
<description: #String label: 'Title'>
<required: true>
<length: 150>
^title
Post>>body
<description: #Memo label: 'Body'>
<required: true>
^body
Post>>isPublished
<description: #Boolean label: 'Published?'>
<default: true>
^isPublished
And generating Magritte descriptions from the metadata and not using class
side descriptions at all. Or maybe just by default, and falling back on
class side descriptions for complex cases.
Ramon Leon
http://onsmalltalk.com
11:44 p.m.
Oh... You're just trying to avoid the description
naming pattern, I
see. I was thinking something more along the lines of something on
the accessors directly...
Post>>author
<description: #SingleOption label: 'Author'>
<options: #findAuthors>
<relatedTo: #SBAuthor>
<displayField: #asString>
<required: true>
^author
Yes, that is certainly possible as well. You just have to write your
own description builder ;-)
I am happy to integrate that.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
9 Jan
9 Jan
12:02 a.m.
Post>>author
<description: #SingleOption label: 'Author'>
<options: #findAuthors>
<relatedTo: #SBAuthor>
<displayField: #asString>
<required: true>
^author
Yes, that is certainly possible as well. You just have to
write your own description builder ;-)
I am happy to integrate that.
Lukas
11:24 a.m.
hi ramon
I thought about that too. The questions after is how much
extensibility do we want.
I do not have the answer just meat questions:
Will we have the declare new pragmas each time you add a new property
to a description.
Do we really want that? what are the benefits? over class side single
description?
I think that this is not clear to me what is really the gain to have
fine-grained pragmas.
On 8 janv. 07, at 23:44, Lukas Renggli wrote:
Oh...
You're just trying to avoid the description naming pattern, I
see. I was thinking something more along the lines of something on
the accessors directly...
Post>>author
<description: #SingleOption label: 'Author'>
<options: #findAuthors>
<relatedTo: #SBAuthor>
<displayField: #asString>
<required: true>
^author
Yes, that is certainly possible as well. You just have to write your
own description builder ;-)
I am happy to integrate that.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
11:34 a.m.
I do not have the answer just meat questions:
Will we have the declare new pragmas each time you add a new
property to a description.
Pragmas in Squeak do not need to be declared, but I would not use
them like suggested.
>> Post>>author
>> <description: #SingleOption label: 'Author'>
>> <options: #findAuthors>
>> <relatedTo: #SBAuthor>
>> <displayField: #asString>
>> <required: true>
>>
>> ^author
In my opinion pragmas should not be used to write code, but to tag
and configure code. I would suggest something like that:
Post>>author
<description: #authorDescription>
^ author
What tells Magritte to look at #authorDescription to get a
description for #author:
Post>>authorDescription
^ MASingleOption new
options: self findAuthors;
relatedTo: SBAuthor;
beRequired;
yourself
Note that there is no need anymore to define an accessor, as this
will be figured out automatically by Magritte.
Do we really want that? what are the benefits? over
class side
single description?
The problem with class side descriptions is that they cannot adapt
themselves to the state of the object. Something that currently
enforces to override #description and to manually patch the
descriptions.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
4:43 p.m.
Pragmas in Squeak do not need to be declared, but I
would not
use them like suggested.
Contrast Magritte with Glorp, both are very powerful, and very pluggable.
Magritte provides meta data about a class, Glorp needs that same metadata
for its descriptions. Magritte is a runtime meta data system, Pragmas are
compile time meta data. However, both Glorp and Magritte require explicit
meta data in the form of code, stored away from the accessor the meta data
belongs to.
Pragmas however, allow one to keep the metadata for a selector, in the
selector itself, a very pleasing option because while I don't mind the
description building bouncing around following description Pragmas, I'd
rather the developer didn't have to, and much of the meta data contained
within Magritte descriptions, really is just compile time meta data.
Obviously Pragmas are less flexible than class side descriptions, I'm not at
all suggesting there's anything wrong with Magritte, it's great, but it
could be simpler to configure, just like Glorp vs. Rails.
Most of the time, when doing database bound web applications, I think one
really could use Pragmas like Rails uses macros to give hints to the
description builder to automate the construction of "MOST" descriptions,
possibly all. It'd be really elegant if one made a field required by simply
adding the <required> Pragma to the accessor itself, and then having the
runtime generate both the Magritte and Glorp descriptions off the class meta
data allowing Rails like behavior and no code required by the developer.
For the more complex cases, you could always have the builder follow
<description: #authorDescription> to the manually configured class side
descriptor, but seriously, most cases will be simple mappings of Strings,
Numbers, Dates, and Memo fields directly to a matching field in the
database, and those, the most common cases, can be totally automated and
work off Pragmas alone. Rails has proven the attraction of zero
configuration to the masses, and if Ruby can do it, Smalltalk can do it
better.
I'm already building an ActiveRecord implementation that builds Glorp
descriptions from Magritte's meta data (working well so far), but while
doing so, it just occurred to me that most of what I need for Glorp could
come directly from Pragmas, and it'd be a shame to build the meta data
twice, so I just thought why not build Magritte descriptors from Pragmas as
well. It's just an idea, but one I think I'm going to explore a little to
see where it leads. Of course, I'll share anything worthy of sharing if
anything pans out, if not, oh well, I'm sure I'll have fun in the process.
Ramon Leon
http://onsmalltalk.com
>> Post>>author
>> <description: #SingleOption label: 'Author'>
>> <options: #findAuthors>
>> <relatedTo: #SBAuthor>
>> <displayField: #asString>
>> <required: true>
>>
>> ^author
In my opinion pragmas should not be used to write code, but
to tag and configure code. I would suggest something like that:
Post>>author
<description: #authorDescription>
^ author
What tells Magritte to look at #authorDescription to get a
description for #author:
Post>>authorDescription
^ MASingleOption new
options: self findAuthors;
relatedTo: SBAuthor;
beRequired;
yourself
Note that there is no need anymore to define an accessor, as
this will be figured out automatically by Magritte.
Do we really want that? what are the benefits?
over class
side single
description?
The problem with class side descriptions is that they cannot
adapt themselves to the state of the object. Something that
currently enforces to override #description and to manually
patch the descriptions.
Cheers,
Lukas
10 Jan
10 Jan
10:42 p.m.
Hi ramon
this is really interesting.
Coming from CLOS I always thought and somehow would like to have
first class meta-objects for instance variable. In fact croquet needs
them (I do not like the xml used but
this is exactly that)
Object subclass: #Person
iv: (PersistentIV named: address; accessors)
or
Object subclass: #Person
requiredIV: 'name';
I have the impression that the way we describe instance variables in
Smalltalk is too monolithic. Strings are not
powerful enough.
A really interesting first steps that we were talking about with
lukas was to have
(Object subclass: #Person)
instVar: 'x y';
instVar: 'z' ;
classVar: 'ZORK'
Could be also a way. I'm not sure. In CLOS people are used to write
such a kind (not quite the same)
of class definition.
Now if the intuition that I get is that if you associate the pragmas
to method you get a
different kind of meta-description. This is true that lukas uses some
description once that
generate the first time their accessors so there is something missing
in Smalltalk from my point
of view (I was born with CLOS mop so this may explain that)
Obviously Pragmas are less flexible than class side
descriptions,
I'm not at
all suggesting there's anything wrong with Magritte, it's great,
but it
could be simpler to configure, just like Glorp vs. Rails.
Yes. I would really to see that.
Most of the time, when doing database bound web
applications, I
think one
really could use Pragmas like Rails uses macros to give hints to the
description builder to automate the construction of "MOST"
descriptions,
possibly all. It'd be really elegant if one made a field required
by simply
adding the <required> Pragma to the accessor itself, and then
having the
runtime generate both the Magritte and Glorp descriptions off the
class meta
data allowing Rails like behavior and no code required by the
developer.
For the more complex cases, you could always have the builder follow
<description: #authorDescription> to the manually configured class
side
descriptor, but seriously, most cases will be simple mappings of
Strings,
Numbers, Dates, and Memo fields directly to a matching field in the
database, and those, the most common cases, can be totally
automated and
work off Pragmas alone. Rails has proven the attraction of zero
configuration to the masses, and if Ruby can do it, Smalltalk can
do it
better.
I'm already building an ActiveRecord implementation that builds Glorp
descriptions from Magritte's meta data (working well so far), but
while
doing so, it just occurred to me that most of what I need for Glorp
could
come directly from Pragmas, and it'd be a shame to build the meta data
twice, so I just thought why not build Magritte descriptors from
Pragmas as
well. It's just an idea, but one I think I'm going to explore a
little to
see where it leads. Of course, I'll share anything worthy of
sharing if
anything pans out, if not, oh well, I'm sure I'll have fun in the
process.
Please let us know.
9 Jan
9 Jan
6:50 a.m.
2007/1/8, Ramon Leon <ramon.leon(a)allresnet.com>om>:
This has one problem: sends do not work and neither do classes. As an
example the following can not be converted to this style:
- PRAddCommand >> #descriptionType
- PRCommandsWidget >> #descriptionCommandClasses
Philippe
Then you can
put your descriptions in a method like:
Address class>>street
<description>
^ MAStringDescription selector: #street
Cheers,
Lukas
Oh... You're just trying to avoid the description naming pattern, I see. I
was thinking something more along the lines of something on the accessors
directly...
Post>>author
<description: #SingleOption label: 'Author'>
<options: #findAuthors>
<relatedTo: #SBAuthor>
<displayField: #asString>
<required: true>
^author
Post>>comments
<description: #ToManyRelation label: 'Comments'>
<relatedTo: #Comment>
^comments
Post>>title
<description: #String label: 'Title'>
<required: true>
<length: 150>
^title
Post>>body
<description: #Memo label: 'Body'>
<required: true>
^body
Post>>isPublished
<description: #Boolean label: 'Published?'>
<default: true>
^isPublished And generating Magritte descriptions from the metadata
and not using class
side descriptions at all. Or maybe just by default, and falling back on
class side descriptions for complex cases.
6315
days inactive
6317
days old
13 comments
5 participants
participants (5)
-
Damien Cassou -
Lukas Renggli -
Philippe Marschall -
Ramon Leon -
stéphane ducasse