scription : 'options:' which depends of an inMASingleOptionDestance attribute

Hi,

An object A have a collection of objects B. each objects B have a collection of objects C, and finnaly each object C have an attribute wich references an object B take in the collection of A.

A 1<=>* B 1<=>* C 1<=>1 B among the Collection of A


My problem :

In a description can I acces to the object which is currently describe?
I use a class variable style 'myCurrentObject' which I feel before compute the descritption but it smells bad... :-/

I hope that I've been understandable ;-)

Florent. :-)



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

why would you need that?
normally you should not mix level. Meta is about meta.



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> why would you need that?
> normally you should not mix level. Meta is about meta.

Are you talking about the following paragraph I wrote?

> This is one of the things I would like to get fixed in the next big
> change of Magritte: have descriptions that belong to the instance
> being defined on the instance side, so that they can differ depending
> on the state of the model.

If yes, the first point is my answer:

* In my opinion descriptions are orthogonal to the Smalltalk meta-
hierarchy. Currently Magritte only allows to automatically compose  
and collect descriptions from the class-side that are then applied to  
the instance side. This sort of makes sense but gets complicated as  
soon as people want to change descriptions depending on the state of  
the object or want to apply descriptions to the class-side itself  
(there is no place to put these). Both use-cases are already possible  
right now, but they are unnecessary complex.

The only problem I see when putting the descriptions to the instance-
side is that you require an instance of the object to get the meta-
model. I don't know if anybody sees a possible problem with this?

* Another thing I would like to change is to get rid of the whole  
MAReferenceDescription hierarchy. Again this is something that is  
much more complex than it should be. Similar to EMOF I would like to  
add a multiplicity attribute directly to the basic description itself.

* And of course use less common selector names for extension methods  
to Object. ;-)

Any other important change-requests?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

No I was talking about the question of florent to have reference to  
the base object in the metadescription.

Stef

On 11 sept. 06, at 08:53, Lukas Renggli wrote:


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

 In fact I've several cases with this problem :

My first example :

I want to built a graph :
1/ I edit the graph
2/ I add some state
3/ I add transitions wich needs the collection of state previously add to the graph

=> lukas have understand I think my problem... it's very usefull to have a description "instance side"...

Steph : it's does not make sens to do this with meta level?


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> * Another thing I would like to change is to get rid of the
> whole MAReferenceDescription hierarchy. Again this is
> something that is much more complex than it should be.
> Similar to EMOF I would like to add a multiplicity attribute
> directly to the basic description itself.

:)

> * And of course use less common selector names for extension
> methods to Object. ;-)

Yah! :)

> Any other important change-requests?
>
> Lukas

Yes, please try to keep everything 3.8 compatible, I see it being my
production platform for quite a while.  It took a long time to trust 3.8,
it'll take a while before I learn to trust 3.9.  Oh, and keep up the great
work, your stuff rocks!


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi All
> The only problem I see when putting the descriptions to the instance-
> side is that you require an instance of the object to get the meta-
> model. I don't know if anybody sees a possible problem with this?
>  
a bit like in MEWA. I don't really care but I found more elegant without
adding instance variables. Wouldn't it be possible to use Pragma on each
inst var accessors ?
> * Another thing I would like to change is to get rid of the whole  
> MAReferenceDescription hierarchy. Again this is something that is  
> much more complex than it should be.
Yes I agree with that... we should have some primitiveDescriptions and
ReferenceDescriptions only. With a boolean telling if the description is
single or multi valuated.  Then, a MAOptionDescription would be a
MAStringDescription with say indexed=true and maybe a cardinality var (?).

Also, I thing we need to have the possibility to associate
referenceProperties either with existing instances (of a class)  or with
new created ones (of the same class).

> Similar to EMOF I would like to  
> add a multiplicity attribute directly to the basic description itself.
>  
EMOF will allow to represent the behavior of domain classes ?
>
> Any other important change-requests?
>
>
>  
I have some though they may be unrealistic ;)

- Would it be possible to declare dependencies between descriptions ?
For instance, to avoid some combinations of value because of semantics
reasons or also to shrink another description domain. Would it worth
reifiing the concept of domain to achieve that?  My concern is more
about knowledge representation, ontology-like. I think we miss a tool
like that in squeak/ST and Magritte seems close to that. Magritte allows
to meta described a domain ? and even more... as it seems to me that we
can metadescribed a bit everything (a GUI, descriptions themselves,
etc...). How do you position Magritte compared to an ontology tool ?
(especialy with this one:
http://www.old.netobjectdays.org/pdf/00/slides/knublauch_pr.pdf or
http://www.knublauch.com/publications/KBeans-Technical-Report-FAW.pdf)
Maybe having an ontology tool would mean to have it's own "ontology"
model that in turn can be described with Magritte...

- For instance, some conditions are now difficult (or impossible to
model). Now it seems to me that we can mainly add unary constraints. It
could be convenient to add binary conditions, that would do delayed
validation (diplaying warnings for example). I tryied to implement a
simple model (like in the example of the slides of the previous link,
see the attached picture of the class diagram) with some constraints and
I just don't know how to do that whith Magritte right now. I joined a
"first try" (attached .st file). Subclassing was not necessary but I
think it's good to illustrate waht we can do or not.
Is it possible to discuss on this model and see how magritte can help to
model it. Do you want Magritte to model such kind of domains ? or is it
too much "knowledge", "OCL" oriented ?

- Last and more fanciful, after seeing dabble :) I was wondering if it'd
be possible to transform a StringDescription in another kind of
description (hence modifiing the underliing model and existing
instances) String to date, String to object...  I think that would allow
to have a cool modeling tool but it must be out of the scope of Magritte....

Hope there are some interesting ideas ;) ...

Cheers,
Cédrick

Hi

Ok my previous email was not clear, I'll try to shorten it ! Please tell
me if it's unclear, unrealistic, too complicated...or just stupid !
Given the model below, I'd like to discuss some points:

(1) Concerning the link spouse

- Idealy, assigning spouse should be done with an existing instance of
Person, or with a new created one. Magritte actual version only allows
to create a new Person (tell me if I'm wrong). I once tried to do a
variation of MAToOneRelationDescription adding a  repository of existing
instances). Is it somethink you'd like Magritte to  allow ? According to
me, having a kind of repository for existing instances in a given
context should be interesting. What do you think ?

- Also on the same example, assigning a spouse to a person  must assign  
the  opposite (spouse spouse: aPerson) as it's a bidirectionnal
relation. Is it something you'd like to address (unidirectional and
bidirectional references) ?

(2) Validation Condition

- It sems to me that MAValidation allow to model unary contraints like
value of lastName can't be nil, or valid value of marital status are in
the list #(unmarried married widowed). Bot for more complicated
constraints (binary, constraints on instances...) it seems impossible to
me. For instance, if a person maritalStatus is set to unmarried, then
the person cannot have children (this is the model example ;) ). Would
you like to allow to model that kind of constraints or is it out of the
scope of Magritte ? I think this is becoming very complex (CSP field,
rule based...) especially if we want to do that on the fly but maybe
doing a check afterwhile could be more realistic...

I stop here and I hope it's a bit clearer at least point (1)... Is it ?
Do you understand my concern ? If not can you tell me the modeling
limits of Magritte ? What you want it to be or not...

Thanks you

Cédrick


> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
>  

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Given the model below,
oups... you'll find it here:

http://88.191.19.63/ressources/model/constrainedModel.png

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> - Also on the same example, assigning a spouse to a person  must  
> assign
> the  opposite (spouse spouse: aPerson) as it's a bidirectionnal
> relation. Is it something you'd like to address (unidirectional and
> bidirectional references) ?

Yeah, this is something that is currently missing. Magritte does not  
work well with cyclic object graphs. You currently have to explicitly  
break and restore the graph at some point.

It is already possible, you have to add your validation rules to the  
container instead. I agree that the current implementation is not  
that ideal.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi
I have no idea how to do that :)...
Is it because of the memento ? For me, memento is about making a copy of
an object, work on the copy and commit it... but if we need to access
existing objects in the model (while there are modified), we only have
the non-modified version... I had a case where I needed that.

What if we directly access the right object after having made a copy of
it (so we have the possibility to rollback). Can the straight memento
(pr another one) allow to do that ?

I think a genealogy tree would be a good example to work on and discuss
(could be fun too :) ). But I think we really miss a kind of repository
of existing objects. Do you think it's important for the next version of
Magritte ?
Do you have an idea to do that in a nice 'standard' way ? adding a class
instance variable ?...

Person

firstName(s) ->list of String descriptions not to be duplicated
lastName ->
sex ->
birthDate ->
deathDate :( ->
/age (ro) ->computed, I think it's ok as far as a coputed value does not
depend on another object -
dad -> on eligible existing one (sex + diff birthdate) or create a new
one - plus add itself as a chidren
mum -> same as previous
maritalStatus -> bidirectional + constraint on names (for the example)
spouse -> bidirectional
children -> on eligible existing one or create a new one - plus add
itself as a parent and the spouse as the other parent (if defined and
still for the example)

Does a model like that seem realizable ?

Oh ok, I wasn't aware of that :) I'll try it...

Thanks for your answers

Ce'drick

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

>> Yeah, this is something that is currently missing. Magritte does not
>> work well with cyclic object graphs. You currently have to explicitly
>> break and restore the graph at some point.
>
> I have no idea how to do that :)...

I usually do the following:

- Remove the description that creates cycles from the containers  
before starting the interpreter, for example to displaying the editor.

- Keep the cyclic paths (back-refs) lazily initialized, so that they  
get automatically generated when a new object is added.

> Is it because of the memento ? For me, memento is about making a  
> copy of
> an object, work on the copy and commit it... but if we need to access
> existing objects in the model (while there are modified), we only have
> the non-modified version... I had a case where I needed that.

No this has nothing to do with the memento. The memento is a snapshot  
of a described state. It has more to do with Magritte itself, it is  
not aware of possible recursions, something that I also want to  
enhance in the next version.

> I think a genealogy tree would be a good example to work on and  
> discuss
> (could be fun too :) ). But I think we really miss a kind of  
> repository
> of existing objects. Do you think it's important for the next  
> version of
> Magritte ?

You mean a repository of descriptions?

I tried to avoid this in the current version, because of uniqueness  
and equality of descriptions. If we want to have such a repository we  
need to introduce sort of an UUID for descriptions, I am afraid.

> [...]
>
> Does a model like that seem realizable ?

It is certainly possible, but it might get very complicated. It is a  
good use case for future versions of Magritte ;-)

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

>
> No this has nothing to do with the memento. The memento is a snapshot  
> of a described state. It has more to do with Magritte itself, it is  
> not aware of possible recursions, something that I also want to  
> enhance in the next version.
>  
cool :) no I meant instances of a class that is described. Like for the example
of a person, what would be a good generic way to acces instances of
person that exist. This way, when adding a spouse for instance, we can
choose among the (eligible) instances or create a new one. We can make
the repository by ourselves I guess but I think that would be good to
have a kind of accessor strategy for it (saved in the image, in an oodb
...)...
Does it make sense ?

> It is a good use case for future versions of Magritte ;-)
>  
I think so too ;)

Cédrick





_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

 Dear Lukas,

I am having a look at the implementation of MADynamicObject and I was
wondering if you could help me by explaining to me how it works!

I can see that MADynamicObject on: [ 123 ]
should assign the BlockContext [123 ] to be the realSubject of the
MADynamicObject.

What I am failing to understand is at what stage the block is evaluated.
I can see that whenever a message is sent to the MADynamicObject it is
being evaluated before the message is sent. I just cant see where the
code is that does the #value.

thanks in advance

Keith

       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi Keith,

> I am having a look at the implementation of MADynamicObject and I was
> wondering if you could help me by explaining to me how it works!

It is a bad thing, but very convenient.

> I can see that MADynamicObject on: [ 123 ]
> should assign the BlockContext [123 ] to be the realSubject of the
> MADynamicObject.

It is used to put a calculated value into a variable. Whenever you  
send the first message to it, the block gets evaluated and the  
message is performed on the result. It is sometimes convenient to do  
this, such as for the options of a single-selection description that  
should return a list of currently loaded classes and not a list of  
classes that have been available when the description was cached.

As usual with proxies it creates more troubles than it helps. I have  
some ideas to avoid them altogether in a future version of Magritte.

> What I am failing to understand is at what stage the block is  
> evaluated.
> I can see that whenever a message is sent to the MADynamicObject it is
> being evaluated before the message is sent. I just cant see where the
> code is that does the #value.

What I find strange is that a MADynamicObject is ending up in the  
code to serialize. Actually that should not happen, as these are only  
part of a few descriptions that should remain transient. Can you tell  
me the path of references from the object you serialize to the  
instance of MADynamicObject?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

about MADynamicObject and serialization.
> It is used to put a calculated value into a variable. Whenever you  
> send the first message to it, the block gets evaluated and the  
>  
This is the bit that I dont understand, I cant see where the
'evaluation' actually happens. Who does it? Where is the code that says
'aBlock value'?

>   What I find strange is that a MADynamicObject is ending up in the
> code to serialize.
Before persisting a PRContext, I was zapping its properties to nil.
However I had omitted to do the same to the context's command's answer
context, as in the case of a PRAddCommand. So it was in the dictionary
of properties, containing references to components that was causing the
problem. Exactly where WAProxyObject is in there I am not quite sure
since I never got a proper debugger up on it. The
PRCommandAdd-structureClasses appeared to be the one causing trouble,
i.e. a reference to this dynamic object is contained in one of the
components.
----
So now Pier-Magma is looking good to go. My main objective was to be
able to have the Pier data persisted outside of the image so that an
'upgrade' of the image would be straightforward.

There are (at least) two more issues to consider if Magma-Pier is to be
a tour-de-force.

1) At the moment pier-magma marks objects for rematerialisation as
needed, one-by-one. Magma can be configured for different
read-strategies, so performance could be greatly increased (so I am
told) if the read strategy re-materialised on a page-by-page or
kernel-by-kernel basis (for a multi kernel site).

2) Using a non-shared MagmaSession takes time to get the initial session
on the database (it could hold a cached session ready in order to
improve this), but when the session is expired the objects may be free
to be purged from the image. (Thinking about it I suspect that this will
not happen automatically with my current implementation, but it should)

My current preferred approach is to use a shared MagmaSession where
there is only one MagmaSession for all the seaside sessions. Effectively
this caches every used object in memory, and the opportunity for
allowing objects to be purged/gc'd is less clear. I am assuming that
Magma doesnt do an explicit purge, but relies upon the application to
'let go' of unneeded objects for gc to tidy up.

Keith

 

               
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> about MADynamicObject and serialization.
>> It is used to put a calculated value into a variable. Whenever you
>> send the first message to it, the block gets evaluated and the
>>
> This is the bit that I dont understand, I cant see where the
> 'evaluation' actually happens. Who does it? Where is the code that  
> says
> 'aBlock value'?

#doesNotUnderstand: is implemented in the superclass. It then calls  
#realSubject what is implemented like this:

realSubject
        ^ super realSubject on: UnhandledError do: [ :err | nil ]

#on:do: evaluates the block which is returned by the super-call to  
#realSubject. Also see the tests.

> However I had omitted to do the same to the context's command's answer
> context, as in the case of a PRAddCommand. So it was in the dictionary
> of properties, containing references to components that was causing  
> the
> problem. Exactly where WAProxyObject is in there I am not quite sure
> since I never got a proper debugger up on it. The
> PRCommandAdd-structureClasses appeared to be the one causing trouble,
> i.e. a reference to this dynamic object is contained in one of the
> components.

Yes, you don't need the answer context. That can be rebuilt if  
necessary.

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki