FAME not ensuring
Locked
 
|
Hi.
So if I’m not mistaken _ensure_ is meant to create referred data if it’s missing. But when you look at: ensureClass: var var isBehavior ifTrue: [ ^classDict at: var ]. var isSymbol ifTrue: [ ^classDict at: (self class environment at: var) ifAbsent: [ metaDict at: var asString ]]. var isString ifTrue: [ ^metaDict at: var ]. [ false ] assert. it’s not ensuring anything. Isn’t there supposed to be something like: metaDict at: var asString ifAbsent: [ self processClass: var asClass ] This really frustrates me about FAME. You cannot tell it "someObj asMSE”. You have to write a tons of pragmas, then do some shenanigans with metamodels and only then you can get serialisation working. Looks like stone age. Sorry for jumping on all the things like that, it’s just that Moose - related things remind me of Java… Uko _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Yuriy, This kind of messages are not particularly useful for anything. Let's try to transform it into something positive. Are you unhappy with the behavior or with the name? Do you have an actual proposal for improvement?
Doru On Mon, Nov 11, 2013 at 1:41 PM, Yuriy Tymchuk <[hidden email]> wrote: Hi. "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I have a big proposal but I won’t have time to implement it :(.
As for fame it would be nice to change something. If the idea is gust about getting a class we can call it getClass:. If it should really ensure, then if class metamodel is missing it should be created. I can do that, the question is what is the grand vision. In general I like to have the tools that think for me. And then to tweak them if needed. For example to export something to MSE you can just export all instance variables buy default and then someone could add meta descriptions to change the behaviour to suite his needs. Same goes for Moose. The Finder could show all instance variables. And then if we need to improve it, we could tweak it. As for me the entry level is too high. It would be nice if we could tell people something like: you can browse whatever you want. Now when you need to make it better you can use this, and that. This is the thing I experienced with FAME. I followed Moose methods of MSE exporting. It was really hart. You can get a class of each object. You can check all the methods of that class for FAME annotations. So what is the reason of creating a separate meta tower and specifying explicitly all the classes? But as I’ve already told, I don’t have time to do something like this at the moment, moreover I have no idea if anyone else likes this. But FAME method should be fixed :). Cheers Uko On 11 Nov 2013, at 16:46, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
On Mon, Nov 11, 2013 at 5:03 PM, Yuriy Tymchuk <[hidden email]> wrote:
Just describe it.
It seems to me that you do not want Fame at all. Instead you just need a serialization for your objects. So, perhaps Fuel is more appropriate for your needs.
Well, you can :). Just use the GTInspector on any object and you have exactly what you are asking for (and a bit more). You can easily extend both the GTInspector and the MooseFinder with methods in your objects that are annotated with corresponding pragmas.
For example, showing all variables of an object is done in the methods below: Object>>gtInspectorStateIn: composite <gtInspectorPresentationOrder: 10>
composite custom: (GTObjectVariablesBrowser new browser startOn: self) GTObjectVariablesBrowser>>variablesIn: composite
composite table showOnly: 50; display: [ :anObject | anObject gtInspectorRetrieveVariableValuePairs ];
sorted: [:assoc1 :assoc2 | assoc1 key < assoc2 key]; column: 'Variable' evaluated: [:assoc |
[ Text fromString: assoc key asString ] on: Error do: [ Text string: 'error printing' attribute: TextColor red ] ];
column: 'Value' evaluated: [:assoc | [ Text fromString: (assoc value printString contractTo: 50) ]
on: Error do: [ Text string: 'error printing' attribute: TextColor red ] ]; send: #value; morphicSelectionAct: [:list | list selection value browse ] icon: GLMUIThemeExtraIcons glamorousBrowse
on: $b entitled: 'Browse'
I do not understand.
Several. First, it was a really fun research project five years ago. I was only external contributor, but it is a nice tiny model.
Seriously, one goal of Fame is to provide (meta-)model validation. There clearly is room for other types of models, but this little checking comes in handy when we generate the meta-model implementation in other languages like Java. For example, VerveineJ uses the Java Fame implementation to generate the FAMIX meta-model based on the MSE derived from the annotations that come from Moose in Pharo. That is both cool and highly valuable. But, it does come with the price of being less transparent for simple use cases.
Can you open an issue please? Doru
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Uko2
On 11/11/2013 01:41 PM, Yuriy Tymchuk wrote: > Hi. > > So if I’m not mistaken _ensure_ is meant to create referred data if it’s missing. But when you look at: > > ensureClass: var > > var isBehavior > ifTrue: [ ^classDict at: var ]. > var isSymbol > ifTrue: [ > ^classDict at: (self class environment at: var) > ifAbsent: [ metaDict at: var asString ]]. > var isString > ifTrue: [ ^metaDict at: var ]. > > [ false ] assert. > > it’s not ensuring anything. Isn’t there supposed to be something like: > > metaDict at: var asString > ifAbsent: [ self processClass: var asClass ] > > > This really frustrates me about FAME. You cannot tell it "someObj asMSE”. You have to write a tons of pragmas, then do some shenanigans with metamodels and only then you can get serialisation working. Looks like stone age. Sorry for jumping on all the things like that, it’s just that Moose - related things remind me of Java… Half of the time I forget some pragma somewhere, and each time I have to create a n-to-n relationship, I have to think twice, and then think twice again. I would really love to have a real generator: a small tool that I could use to create Fame-classes and/or relationships and that would do all the work But for one I don't have much time, and even worst, last time I tried (on a sunny sunday afternoon), I just had to admit it was above my limited intelligence to work at three different levels of abstraction at the same time. I have been trying to enrol some bright mind on the project, but with no success for the time being. :-( nicolas PS: OK, this email is not useful to the community, but I really needed to release all this frustration -- Nicolas Anquetil -- RMod research team (Inria) _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |