C# properties and getter/setter access

[fwoolz]

C# allows the get and set methods of a property to have different access levels. For example, the following:

Code: [Select]

public TreeView CurrentTree { get; protected set; }
is perfectly acceptable. Yet EA does not allow different access levels for get and set for C# properties (it does for other languages).

UPDATE:

The property above could be shown something like this:

+CurrentTree {+get; #set} : TreeView

Provided that no sacred tenets of UML are transgressed.

[Paolo F Cantoni]

Provided that no sacred tenets of UML are transgressed.

Therein may be the rub, Fred.

Unfortunately, there are a number of tenets of UML that are just wrong...  An example is namespacing.  UML (as far as I'm aware) treats packages as namespaces and so enforces that the containment/classification structure and the namespace must be aligned.  In fact, they are quite independent.  As you'll know, I've made various postings on the need to have folders that aren't part of the namespace.

The problem is that UML is (believe it or not) a Modelling language and so should be able to model existing, valid, programs in whatever language is covered by the various profiles.  It can't.

In this case (accessor access levels), since EA allows this for other languages, is a simple inconsistency.  But it may well be that UML doesn't actually allow separate access levels (I can't check that right now).

I used to have the same problem with Embarcadero ER/Studio which insisted you could only build IDEF1X models.  This ruled out a whole class of perfectly valid relational models and databases.  It took me 7 years of persistence to get that changed...

bruce touched on similar points in GGRRRRRRRRRRRRRRRGGGGGHHHH!*

Paolo

[Eve]

Well, Paolo is mostly correct.

There are at least two issues in play.  What UML allows and how EA fits what a programming language into that.

For properties in most languages they exist as two functions.  .Net introduces a construct which is essentially an attribute derived from one or more implicit methods.  (Delphi has a similar construct but the methods are explicit.)

In EA this is modelled as a single method, with a single scope/visibility field.  That decision predates my involvement, but unless I'm mistaken the language support for difference accessors having different scopes was introduced after that point.

If I was doing it from scratch now I might specify that this was modelled as a derived attribute with fields specifying the methods to use for each accessor... But I'm sure there would be something wrong with that too.