Home » Archived » B3 » Ideas from the b3 symposium at ESE
| Ideas from the b3 symposium at ESE [message #493774] |
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
|
|
|
| Re: Ideas from the b3 symposium at ESE [message #493939 is a reply to message #493774] |
Wed, 28 October 2009 14:48  |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Some more feedback on syntax today...
- We don't really need the for( x in ...) syntax as there is set
operation - consider dropping it.
- henrik
On 10/28/09 12:05 AM, Henrik Lindberg wrote:
> 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
>
>
>
|
|
|
| Re: Ideas from the b3 symposium at ESE [message #493942 is a reply to message #493774] |
Wed, 28 October 2009 14:50 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
More things...
- The "hidden" keyword is no longer needed since it is just as easy to
name the part of the group that should be returned, and just return that
instead of the entire group.
- henrik
On 10/28/09 12:05 AM, Henrik Lindberg wrote:
> 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
>
>
>
|
|
| | |
| Re: Ideas from the b3 symposium at ESE [message #494626 is a reply to message #493774] |
Sun, 01 November 2009 11:33 |
|
On 10/28/2009 12:05 AM, Henrik Lindberg wrote:
> - 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).
>
I'm not sure I like this idea. You can turn it around and claim that it sucks that you have to remember the name and
spelling of each parameter in case you need to add new code using a text editor. In many cases it's self evident anyway:
rootPath.isPrefixOf(y);
myList.indexOf(y);
comparator.compare(x,y);
etc. and in many other cases you don't send constants but a named variables/properties which in turn increases readability:
siteP2($site.pack200, $signing.type);
I think I would rather avoid parameter names in the call. It's easy enough to use tool tips in the IDE and while it
occasionally may increase readability when using a text editor, it also makes editing harder and increases the noise.
- thomas
|
|
|
| Re: Ideas from the b3 symposium at ESE [message #494627 is a reply to message #494626] |
Sun, 01 November 2009 11:46 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
It is also not in the xtend/expression syntax. To help those that are
doing command line type work, there could be an text based interactive
shell that helps with things like this - could be the same as the debugger.
- henrik
On 11/1/09 12:33 PM, Thomas Hallgren wrote:
> On 10/28/2009 12:05 AM, Henrik Lindberg wrote:
>> - 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).
>>
> I'm not sure I like this idea. You can turn it around and claim that it
> sucks that you have to remember the name and spelling of each parameter
> in case you need to add new code using a text editor. In many cases it's
> self evident anyway:
>
> rootPath.isPrefixOf(y);
> myList.indexOf(y);
> comparator.compare(x,y);
>
> etc. and in many other cases you don't send constants but a named
> variables/properties which in turn increases readability:
>
> siteP2($site.pack200, $signing.type);
>
> I think I would rather avoid parameter names in the call. It's easy
> enough to use tool tips in the IDE and while it occasionally may
> increase readability when using a text editor, it also makes editing
> harder and increases the noise.
>
> - thomas
|
|
|
| Re: Ideas from the b3 symposium at ESE [message #589661 is a reply to message #493774] |
Wed, 28 October 2009 14:48 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Some more feedback on syntax today...
- We don't really need the for( x in ...) syntax as there is set
operation - consider dropping it.
- henrik
On 10/28/09 12:05 AM, Henrik Lindberg wrote:
> 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
>
>
>
|
|
|
| Re: Ideas from the b3 symposium at ESE [message #589666 is a reply to message #493774] |
Wed, 28 October 2009 14:50 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
More things...
- The "hidden" keyword is no longer needed since it is just as easy to
name the part of the group that should be returned, and just return that
instead of the entire group.
- henrik
On 10/28/09 12:05 AM, Henrik Lindberg wrote:
> 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
>
>
>
|
|
| | |
| Re: Ideas from the b3 symposium at ESE [message #589727 is a reply to message #493774] |
Sun, 01 November 2009 11:33 |
|
On 10/28/2009 12:05 AM, Henrik Lindberg wrote:
> - 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).
>
I'm not sure I like this idea. You can turn it around and claim that it sucks that you have to remember the name and
spelling of each parameter in case you need to add new code using a text editor. In many cases it's self evident anyway:
rootPath.isPrefixOf(y);
myList.indexOf(y);
comparator.compare(x,y);
etc. and in many other cases you don't send constants but a named variables/properties which in turn increases readability:
siteP2($site.pack200, $signing.type);
I think I would rather avoid parameter names in the call. It's easy enough to use tool tips in the IDE and while it
occasionally may increase readability when using a text editor, it also makes editing harder and increases the noise.
- thomas
|
|
|
| Re: Ideas from the b3 symposium at ESE [message #589735 is a reply to message #494626] |
Sun, 01 November 2009 11:46 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
It is also not in the xtend/expression syntax. To help those that are
doing command line type work, there could be an text based interactive
shell that helps with things like this - could be the same as the debugger.
- henrik
On 11/1/09 12:33 PM, Thomas Hallgren wrote:
> On 10/28/2009 12:05 AM, Henrik Lindberg wrote:
>> - 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).
>>
> I'm not sure I like this idea. You can turn it around and claim that it
> sucks that you have to remember the name and spelling of each parameter
> in case you need to add new code using a text editor. In many cases it's
> self evident anyway:
>
> rootPath.isPrefixOf(y);
> myList.indexOf(y);
> comparator.compare(x,y);
>
> etc. and in many other cases you don't send constants but a named
> variables/properties which in turn increases readability:
>
> siteP2($site.pack200, $signing.type);
>
> I think I would rather avoid parameter names in the call. It's easy
> enough to use tool tips in the IDE and while it occasionally may
> increase readability when using a text editor, it also makes editing
> harder and increases the noise.
>
> - thomas
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:39:11 GMT 2024
Powered by FUDForum. Page generated in 0.04312 seconds |
] 
Search
Help
Register
Login
Home
