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
