"Facets" or how to reduce available members...

[radek jedrasiak]

Hi all,

this is about an idea for a language feature. Any feedback welcome.

To start with:

This is about a language feature, which would allow
to filter the set of available members of a type within a defined scope,
it is also about defining "views" for types. It's about
controlling what features / feature sets of external libraries / components
are used actively by the application programmers.

Delphi .NET class helpers (CHs) allow extending a given type
without changing the types identity. It was mentioned several
times already that Chs are not meant to be used for everyday
coding work, and where added just to allow to "connect" the VCL
with the .NET framework efficiently.

Having worked with OO languages for a while,
and having used alot of third party components I think that
quite the oposite is what application programmers would
benefit from.

Take a look at typical a component on your palette. It provides
myriads of members which deal with the different situations and
systems it has to communicate with. For a visual control f.e. there
are members to deal with the static visual appearance (like position,
site, anchors, colors etc), there are members controlling the
displayed data (like caption, colors, formats etc), and there are members
controlling a data binding (like datasource linkage). There are too members
which are only there because they are needed by the system to stream
the component, members inherited from some base objects etc.etc.
The visual editors for the components allow to setup a filter or grouping
of members when editing components visually. When working with
type "in code" you work always with the whole unfiltered set of members.

Now, when using a component within your source usually
you are not using ALL of the members at once. Mostly only a subset
of the available members is accessed in one module/class etc.
When writing a layout engine, you probably concentrate on the
layout members and not on the data binding features of a component.
When working with the data the component delivers you are not
interested in the layout properties of the component. etc. etc.
(Well ok, this is probably a little bit optimistic ... real code, real projects
tend to end up with ALL members being used in ALL places
.... real world is a bad place )

When looking over the shoulder of my fellow programmers I often
see them searching for the right member of a type to use. Most of
the time they have to scan ALL of the members of type, and in most
cases the majority of the presented members (presented by CodeInsight, IntelliSense etc)
are of no use at all for the case at hand.

How about this:

Define a "Facet", which would be something similar to a Interface
definition, meaning it contains only the Signatures of members of
a type the Facet is defined for.

f.e:

public facet Position : Component {
public PositonX : Integer;
public PositonY : Integer;
public void Reposition();
}

This would be the facet "Position" defined for the type "Component".
PositionX & Y and Reposition() are members of Component,
and here they are defined to be part of the facet Position.

Now, when working with Component types this facet - when known/visible -
would filter the available members of the Component:

void foo{
Component comp = new Component(...)
comp.PositionX := 10; // (1)
comp.Name = 'newName'; // syntax error: members 'Name' not visible here
}

When calling for IntelliSence/CodeInsight at the marked line (1),
only PositionX, PostionY and Reposition() would appear in the
selection of members of comp.
Access to members not in the facet would be a syntax error.

An alternative idea could be to allow facet-names to be used
when instantiating a type like this:

void foo{
Component.Position comp = new Component(...) // I want to use the "Positon" members only
comp.PositionX := 10; // !!!
}

This would make the usage of the facet more explicit, but also
less strict as now the decision if the facet is used can
be taken every time the Component type is used.

In the first case the implicit facet has only to be "activated"
(by adding a reference to an assembly which defines it)
and then it defines the available symbols for a type within the whole module.

What do you think?

Cheerio
Radek

 

[Nicole Calinoiu]

Hi all,

this is about an idea for a language feature. Any feedback welcome.
...
void foo{
Component.Position comp = new Component(...) // I want to use the "Positon" members only
comp.PositionX := 10; // !!!
}

There are already several ways to accomplish the same goal without adding a
new language feature. For example, the component discussed above could
define a Position property which exposes an instance of a Positioner class
that, in turn, defines properties X and Y and method Move. IMO, the real
problem here isn't the lack of a language feature such as you described but,
rather, a failure to consider the problem of very long member lists when
designing components. The addition of a facet feature would probably
encourage even more bad design, causing more problems than it would fix.

 

[radek jedrasiak]

There are already several ways to accomplish the same goal without adding a
new language feature.

There's no way to change the structure of a given third party component.
I think a benefit of the proposed feature would be the possibility
to bring in some order from the outside and without the need to change
third party code f.e.

I think it would help to USE available components better.

For example, the component discussed above could
define a Position property which exposes an instance of a Positioner class
that, in turn, defines properties X and Y and method Move. IMO, the real
problem here isn't the lack of a language feature such as you described but,
rather, a failure to consider the problem of very long member lists when
designing components.
The addition of a facet feature would probably
encourage even more bad design, causing more problems than it would fix.

Very true. In the theoretical world of software
design, components and classes use classes to separate the
different concerns.
In the everyday world programmers are working today,
and probably will work for some years to come,
they are dealing with long members lists. Sure we can
wait unitl all bed component "designers" resign, or learn
better.

If the addition of the feature "encourages even more bad design",
I wonder how we could encourage good design regarding this.
You can't! People are lazy. They don't want to navigate a whole
object path until they can change a certain property of an object/component.
That's the practical reason for long member lists, in component at least.

Providing the feature does not prevent good design at all.
It gives the *application* designers one addtional tool to control
the applicaiton infrastructure in the first place. Addtionaly
it helps application developers to find the things they are looking
for more easily, and preventing them from using members they
are not supposed to use in a certain module.

cheerio
Radek

 

[Nicole Calinoiu]

There's no way to change the structure of a given third party component.

Implementing a facet in this scenario would presumably involved creating a
wrapper for the component. If one needs to create a wrapper anyway, there
are other ways to reach the same member-grouping goal.

If the addition of the feature "encourages even more bad design",
I wonder how we could encourage good design regarding this.
You can't! People are lazy.

Yep. And they won't use facets either, so you'll still need to create your
own. To encourage good design, complain to the vendor about their bad
design. If they don't respond, complain in public/semi-public via their
support forums or whatever other similar medium might be available. Submit
a nasty review to a magazine. Threaten to take your business elsewhere.
Actually take your business elsewhere. You do have options.

Providing the feature does not prevent good design at all.

I wasn't suggesting that it would. However, IMO, it provides a shortcut via
which a poor design can be hidden too easily.

It gives the *application* designers one addtional tool to control
the applicaiton infrastructure in the first place. Addtionaly
it helps application developers to find the things they are looking
for more easily, and preventing them from using members they
are not supposed to use in a certain module.

You might want to take a look at some of the project control functionality
available via VStudio.NET Enterprise Architect edition. See
http://msdn.microsoft.com/library/e...ConstraintsInEnterpriseTemplatePolicyFile.asp
for some examples of the kinds of control it allows.

 

[radek jedrasiak]

Implementing a facet in this scenario would presumably involved creating a
wrapper for the component. If one needs to create a wrapper anyway, there
are other ways to reach the same member-grouping goal.



Yep. And they won't use facets either, so you'll still need to create your
own.

YES!!!! That's what I'm after. With facets I can use this "badly" desinged
component and add some order to it.

To encourage good design, complain to the vendor about their bad
design. If they don't respond, complain in public/semi-public via their
support forums or whatever other similar medium might be available. Submit
a nasty review to a magazine. Threaten to take your business elsewhere.
Actually take your business elsewhere. You do have options.

Yes these some options. Biz-options only, actually. Developers
also need technical options. Facets are about exactly that.

I wasn't suggesting that it would. However, IMO, it provides a shortcut via
which a poor design can be hidden too easily.

I partly agree. You are right this is also a workaround for the issues
you already stated before.
Addtionaly I think that facets would also provide a tool to
control what and how is used within an application system.
Can't see anything bad with that.

You might want to take a look at some of the project control functionality
available via VStudio.NET Enterprise Architect edition. See
http://msdn.microsoft.com/library/e...ConstraintsInEnterpriseTemplatePolicyFile.asp
for some examples of the kinds of control it allows.

Thanks. The "Enterprise Template Policy File" only can
be applied to the IDE and does not control at all how developers
deal with code in source.
Facets are more about that: compile time control of the way
symbols and members are accessed within a module.

Cheerio
Radek

 

[Nicole Calinoiu]

The "Enterprise Template Policy File" only can
be applied to the IDE and does not control at all how developers
deal with code in source.
Facets are more about that: compile time control of the way
symbols and members are accessed within a module.

Have you considered using custom attributes to achieve this goal? Besides
applying usage restrictions, you might even be able to affect IntelliSense
display. Personally, I still think that creating a "well behaved" wrapper
is a better approach than either facets or an attribute approach. In
addition to allowing control over access to the component members, it also
provides encapsulation of this access in such a way as to minimize the
effort required to adjust an application to work against new versions of the
component.