| Ideas from the b3 symposium at ESE [message #589648] |
Tue, 27 October 2009 23:05 |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
There were some great feedback at the b3 symposium at ESE, and after the
session we ended up continuing the discussion how things could be
further simplified, and how descriptions could be easier to understand
by using good naming.
I am probably going to miss several of the ideas/suggestions that were
brought up, but Stefan Daume was taking notes...
Here are a few of the ideas that were discussed:
- Whenever parameters are passed, the parameter passing should use
names, not just position - it is difficult to read code like func(true,
false, true, false) - what does each of the parameter values do? It is
fine when you are in the IDE and can get popups - but it sucks when you
are in a command line environment. So parameter names should be included
in the call (even if this is not JavaScript compliant syntax).
- People liked the idea of being able to pass parameters to parts as
opposed only relying on global properties being set. Much clearer if
parameters are stated as part of the API. b3 known about the interface,
and hence what can be called, and parameters it requires.
- The terms "group" and "layout" are not all that helpful in conveying
the role they play in a build part. A good word found in the xpand (code
generation for models) is "outlet" - it specifies where output is
supposed to go - which is what a "layout" is primarily intended to
describe. The reverse of "outlet" is "inlet" :) - but why not simply
call these "input" and "output"?
- When a unit declares a requirement, and there is the need to refer to
it again in the same unit file the entire declaration needs to be
repeated. It should be possible to name the requirements at unit level,
just as this can be done in a part's group.
- We have had discussions about the keyword hidden and the setting of
the alias of sections in a group. One idea from the xpand framework is
to name things postfix using the keyword "as n" - i.e. state:
'osgi.bundle/org.myorg.mybundle.wunderbar/1.0 as wunderbar;' instead of
'wunderbar = osgi.bundle/org.myorg.mybundle.wunderbar/1.0;'. The keyword
"as" is used in similar way in many different places "include nnn as x",
etc, and it is probably clearar that it is an alias when seing the word
"as", instead of just an assignment.
- One of the first parts we designed was the resolvers/repositories
section. And the constrcut proposed there are more complicated than what
they need to be. We also need to look at how options are defined -
currently, this is done with advice - but it it could be made easier
(even if the common cases are trivially stated in advice form (basically
just name/vaue pairs, it is probably a good idea to support the common
cases with keyword rather than "anything is possible here..."
- The resolver examples just state a URI, and not how parameters,
passwords, translation of component name to location is done etc. We
need to work that out.
- One of the usage scenarios that we discussed early came up during the
symposium - how is it possible to add more capability to all build units
of a particular kind. It is supposably doable with the current syntax -
i.e. write advice that injects a new part into every unit that
implements a particular interface - but we need to work through this use
case (one think in particular is how to handle "group" and "layout"
statements when writing them as advice. Should it perhaps be possible to
just write a part on a unit, and then inject that part into other units
(i.e. copy the entire "method")? If so, how is execution of such a part
prevented in the unit that defines it? If it should be public in the
unit where it ends up for instance? What happens to the interface -
should it state that it implements an additional interface? If so, is it
possible to have a unit work as an interface definition? Or is it an
"abstract" build unit. If so, what is the syntax in a concrete top level
build unit to use such an abstract unit and inject it into others.
Alternatively, this is specified as something that is done at meta data
translation time, since the intent is that all users of the build unit
should see them after the injection of the new parts.
- A good idea that came up at the symposium was to use model to model
transformations to transform a b3 model into a buckminster model (now
that buckminster input can be handled as models). This means that a
first running engine could be produced without too much work (even if it
only supports a subset - it will still be able to show the most common
cases building). [Thanks oisin for the idea!)
- Again a naming issue. Is "parts" really a good name? When we said that
"parts" are like "methods" in a java class things started to click for
more people - why not call them that? i.e. "methods", or "build methods"
in case of ambiguity. As we are not spelling it out in the syntax, is it
just a matter of terminology. So, if we also change the terminology for
the "group" and "layout", we can say "this is a build method, its input
and output are declared here..." - which I think is a lot clearer that
saying "this is a build part, its group and layout are declared here"
(you have to know the terminology as it is hard to guess what it means).
Regards
- henrik
|
|
|
Powered by
FUDForum. Page generated in 0.02827 seconds
] 
Search
Help
Register
Login
Home
