Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

Hi, Class extensions is at the core of the design of Moose. For example, for a class we have as extensions: - numberOfMethods - isJUnit4TestCase - viewBlueprint and viewBlueprintOn: Now, the question is, when to extend an existing class and when not, given that it might lead to a very large amount of methods. To answer this, let's start from the reason for having the extensions in the first place. We want extensions to unify the scripting and the user interface world. For example: - if we are in a MooseFinder, we can see numberOfMethods in the properties pane, because it is meta-described, and we can use it easily in scripting (each numberOfMethods > 10). - The isJUnit4TestCase is not meta-described, but it's meant to be used as a query facility. - viewBlueprint appears in the menu and it is also meant to be used from the inspector. - viewBlueprintOn: this is particularly useful when it is used inside other Mondrian or Glamour scripts So, all in all, you extend when you have: - a meta-described property - a query method (the best kind are unary ones) - a menu entry - a compose-able script Now, when not to extend? Basically, when you do not fall in the above categories :). Here are some examples: - FAMIXClass>>viewMethods: aCollection inBlueprintLayerNamed: aString on: view I can safely provide this as an example, because created it. This is a method that basically only makes sense in the context of the class blueprint. So, it should be bundled together in a separate helper class. - FAMIXPackage>>configurationOfECell This is basically just a helper method that only makes sense in the context of DSM, so it should better be placed there. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

13 years, 6 months

Some questions

by Andre Hora

Hello, I have two simple questions. In the code below: public MemberTypeBinding(char[][] compoundName, ClassScope scope, SourceTypeBinding enclosingType) { super(compoundName, scope, enclosingType); ... } How many Accesses and References do I have? (do the parameters contain 2 References and the super 3 Accesses). Thanks! -- Andre Hora

13 years, 6 months

what is NIL in the MSE EBNF?

by Stéphane Ducasse

I thought everything should be specified in EBNF and I do not see what NIL is in http://www.moosetechnology.org/docs/mse Stef

13 years, 6 months

what are the meaning of ? and + in http://www.moosetechnology.org/docs/mse

by Stéphane Ducasse

* = 0, 1 or many now what means ? and + + = 1 or many ? optional ? what is the standard used to describe the grammar? Stef

13 years, 6 months

[Better Comment Initiative] FAMIXType

by Stéphane Ducasse

FAMIXType is a generic class representing a type in an object-oriented language. As such a type can have multiple subtypes or supertypes. These are represented by instances of FAMIXInheritance. A type defines methods (operations), attributes. It is also defined in a container often a FAMIXNamespace or a FAMIXPackage, depending of the language. It may also be a class (in case of nested classes). It can also define behavioursWithDeclaredType structuresWithDeclaredType I have a question: what are behavioursWithDeclaredType and structuresWithDeclaredType structure I guess a bit. behaviroWithDeclaredType is for parametrized subclasses? Stef

13 years, 6 months

[Better Comment Initiative]: FAMIXPackage

by Stéphane Ducasse

we have FAMIXPackage represents a package in the source language. A package is different from a namespace (FAMIXNamespace). They both provide a scope, but the namespace does it from a language perspective. For example, in Java concept of package maps both on the FAMIXNamespace and on a FAMIXPackage: - it is a FAMIXNamespace because it provides a lexical scope for the contained entities, and - it is a FAMIXPackage because it describes the physical structure of the system. I propose FAMIXPackage represents a package in the source language, but when the language only mean grouping of entities without scoping. The scoping aspect is captured by FAMIXNamespace. A package is different from a namespace (FAMIXNamespace). A package defines simply a group of entities. A namespace scopes a group of entities (it may implement an import, a name lookup). For example, in Java concept of package maps both on the FAMIXNamespace and on a FAMIXPackage: - it is a FAMIXNamespace because it provides a lexical scope for the contained entities, and - it is a FAMIXPackage because it describes the physical structure of the system. FAMIX extractor usually map Java package to FAMIXNamespace for these reasons.

13 years, 6 months

[Better Comment Initiative]: FAMIXClass

by Stéphane Ducasse

proposition: FAMIXClass represents an entity which can build new instances. A FAMIXClass is a FAMIXType, therefore it belongs to a super/sub lattice (depending on the language) and it holds attributes, methods, structures. FAMIX does not model explicitly interfaces and nested classes. But a FAMIXClass can represent a Java interface (see isInterface query method). Java extractors can nest classes into classes and classes in namespaces. For anonymous classes, classes are simply defined in methods.

13 years, 6 months

5012 tests

by Tudor Girba

Hi, The amount of unit tests run by ci.moosetechnology.org got to 5012. I know it does not say much, but it sounds cool :) Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

13 years, 6 months

About pragma renaming

by Stéphane Ducasse

Hi doru I want to start working on - producing a good FAMIX30 -> So will continue to go over the comments - probably adding package: java at the right places. Now I was thinking that to ease the transition I will duplicate the program MSE FM so that code can continue to work and then later we remove MSE* ones. stef

13 years, 6 months

why mooseName lost its comment?

by Stéphane Ducasse

Hi guys MooseElement>>mooseName "Returns an unique identifier of this entity. This method is mandatory, and must return a Symbol or Integer that uniquely identifies this entity within its model (but not within the entire Moose enivronment, see MooseElement>>mooseID). The return value must not be nil, and must never change. The implementation should be fast, as this key may be used extensivley by the MooseModel or similar facilities." ^self mooseID asString "asSymbol -- check if this really works with Integers as well, else change sender!" was like that and now MooseEntity>>mooseName mooseName | stream | ^ self privateState propertyAt: #mooseName ifAbsentPut: [ stream := (String new: 64) writeStream. self mooseNameOn: stream. ^ stream contents asSymbol ] so why the comment got lost? Stef

13 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev