www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Aliasing protection attributes?

reply Ilya Minkov <minkov cs.tum.edu> writes:
Hello.

One discussion on GUI has raisen the question of Properties as editable 
from outside tools - like Delphi, NetBeans, etc. - not to confuse with 
the language definition of properties, which is vague. I was thinking 
about possible implementation of a tool which would expose fields and 
get/set properties of, for example, GUI widgets, as a set of fixed 
functions and variably generated data to allow applications to access 
these at run time. The tools would need no prior knowledge about the 
classes and properties to manipulate, this knowledge gets exposed at 
run-time by the tool-generated code.

The problem is, the language does not provide a sufficently sharp 
definition of what has to be exposed. One is running a risk to visually 
expose either obscure fields which make sense for access from the 
running code, but have no sane mean to be edited, or stray member 
functions can be misinterpreted for properties when they aren't. What i 
would like to see, is an ability to do something like:

alias public published;

Then, the compiler would treat published properties as public, but the 
tool would be able to distinguish properly and expose only published 
properties.

This solution is not without downsides. Namely, i see that the 
protection attributes are not identifiers, but separate types of tokens, 
which means that it might not be implementable sanely, here or with 
other pasing systems - especially the external tools (editors, etc.) may 
not always be forced to parse the code completely but may nontheless 
need to distinguish protection properties from everything else.

Other approaches to the problem of exposable properties and the like 
extensions:
  - create a preprocessing framework which every tool would have to use, 
or which would be able to adapt to every tool which doesn't have direct 
support for it.
  - specifically with properties, one may resort to either specifying 
them externally, in the comments (the information would be extracted by 
the documentation tool), or as code. With code: is there any elegant 
solution?

Opinions? Suggestions?

-eye
Nov 09 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 09 Nov 2004 21:57:07 +0100, Ilya Minkov <minkov cs.tum.edu> wrote:

 Hello.

 One discussion on GUI has raisen the question of Properties as editable 
 from outside tools - like Delphi, NetBeans, etc. - not to confuse with 
 the language definition of properties, which is vague. I was thinking 
 about possible implementation of a tool which would expose fields and 
 get/set properties of, for example, GUI widgets, as a set of fixed 
 functions and variably generated data to allow applications to access 
 these at run time. The tools would need no prior knowledge about the 
 classes and properties to manipulate, this knowledge gets exposed at 
 run-time by the tool-generated code.

 The problem is, the language does not provide a sufficently sharp 
 definition of what has to be exposed. One is running a risk to visually 
 expose either obscure fields which make sense for access from the 
 running code, but have no sane mean to be edited, or stray member 
 functions can be misinterpreted for properties when they aren't. What i 
 would like to see, is an ability to do something like:

 alias public published;

 Then, the compiler would treat published properties as public, but the 
 tool would be able to distinguish properly and expose only published 
 properties.

 This solution is not without downsides. Namely, i see that the 
 protection attributes are not identifiers, but separate types of tokens, 
 which means that it might not be implementable sanely, here or with 
 other pasing systems - especially the external tools (editors, etc.) may 
 not always be forced to parse the code completely but may nontheless 
 need to distinguish protection properties from everything else.

 Other approaches to the problem of exposable properties and the like 
 extensions:
   - create a preprocessing framework which every tool would have to use, 
 or which would be able to adapt to every tool which doesn't have direct 
 support for it.
   - specifically with properties, one may resort to either specifying 
 them externally, in the comments (the information would be extracted by 
 the documentation tool), or as code. With code: is there any elegant 
 solution?

 Opinions? Suggestions?


If we specify them externally then we run the risk of the external 
specification not matching the actual code, I think we want to avoid this 
if possible.

Can we not have a keyword that the compiler simply ignores? either:
1. we get an official keyword
2. we invent a mechanism for defining custom keywords

after all the compiler doesn't care about whether it's 'published' or not, 
it's not going to compile any differently is it?


code?


Is it only public members that should be published? What about:

class Foo {
   Foo(int guiMode, char[] name) {
   }
}

might we want to expose the constructor parameters also?
Or, would we force the above to be re-written as:

class Foo {
   int guiMode;
   char[] name;
   Foo() {
   }
}

if so, what happens when guiMode should not be set at any time except 
construction?
i.e. it's really a private or public readonly member.

Is the solution then to use getter/setters (properties) i.e.

class Foo {
   private _guiMode;
   int guiMode() { return _guiMode; }
}

perhaps we simply 'publish' all getter/setter combinations (and 
constructor parameters) and force people to write in that style for their 
GUI components? It would at least be consistent.

Those are my ramblings anyway..

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Nov 09 2004
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:
Ilya Minkov wrote:

[...]

  or as code. With code: is there any elegant 
 solution?
 
 Opinions? Suggestions?
 
 -eye


Whe should be able to register properties in a directory that can be 
evaluated at run-time, per widget. Qt does it that way. Only Trolltech 
has a pre-processor to generate the directory, or meta-object.

Could something like the following be made to work?

#class Widget





#class ButtonWidget : public Widget









Then a GUI builder loading this class could present the properties by 
name, and knows the associated function pointers and types.

I always wonder whether the vtbl in classinfo can be used in this regard.

Bastiaan.
Nov 10 2004
parent Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:
Bastiaan Veelo wrote:

 Whe should be able to register properties in a directory that can be 
 evaluated at run-time, per widget. Qt does it that way. Only Trolltech 
 has a pre-processor to generate the directory, or meta-object.
 
 Could something like the following be made to work?
 
 #class Widget





 #class ButtonWidget : public Widget








 
 Then a GUI builder loading this class could present the properties by 
 name, and knows the associated function pointers and types.


But whe should be careful not to bloat the lib with this info when it is 
not used. I.e., version-out the publish method and maybe replace the AA 
with a pointer to meta-object that may be null.

A GUI builder could compile the class prior to dynamically linking, with 
the version on.

Bastiaan.
Nov 10 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
One discussion on GUI has raisen the question of Properties as editable 
from outside tools - like Delphi, NetBeans, etc. - not to confuse with 
the language definition of properties, which is vague. I was thinking 
about possible implementation of a tool which would expose fields and 
get/set properties of, for example, GUI widgets, as a set of fixed 
functions and variably generated data to allow applications to access 
these at run time. The tools would need no prior knowledge about the 
classes and properties to manipulate, this knowledge gets exposed at 
run-time by the tool-generated code.

The problem is, the language does not provide a sufficently sharp 
definition of what has to be exposed. One is running a risk to visually 
expose either obscure fields which make sense for access from the 
running code, but have no sane mean to be edited, or stray member 
functions can be misinterpreted for properties when they aren't. What i 
would like to see, is an ability to do something like:

alias public published;

Then, the compiler would treat published properties as public, but the 
tool would be able to distinguish properly and expose only published 
properties.

This solution is not without downsides. Namely, i see that the 
protection attributes are not identifiers, but separate types of tokens, 
which means that it might not be implementable sanely, here or with 
other pasing systems - especially the external tools (editors, etc.) may 
not always be forced to parse the code completely but may nontheless 
need to distinguish protection properties from everything else.

Other approaches to the problem of exposable properties and the like 
extensions:
  - create a preprocessing framework which every tool would have to use, 
or which would be able to adapt to every tool which doesn't have direct 
support for it.
  - specifically with properties, one may resort to either specifying 
them externally, in the comments (the information would be extracted by 
the documentation tool), or as code. With code: is there any elegant 
solution?

Opinions? Suggestions?
Nov 10 2004