Private vs. protected, naming conventions etc.
I've been grappling with a couple of frustrations with Forte, and I'm
interested in feedback from others on this list regarding approaches
they may have adopted to address these.
One is that in the Forte workshops there is no way to view only the
public methods and attributes of a class (we're still using V2 here; I'm
assuming that V3 has not changed this). While referring to appropriate
technical documentation for a class is obviously important, I still find
myself opening up classes in the workshops to inspect the methods and
attributes available. (What I really want to see is an integrated class
browser. I sure hope Forte is working on something like this, or will
open up their development environment to support third-party extensions.
But that's an aside.)
A convention I just recently adopted in my work is to name private
methods and attributes with a beginning underscore ("_"). That way the
private elements are sorted to the top of the list and can be easily
differentiated from public elements. I'm curious, though, whether others
have adopted similar or different approaches.
I've also felt a bit frustrated over the lack of support for protected
attributes/methods for TOOL classes. This strikes me as a rather
bothersome shortcoming. The only approach I can think of is to make such
elements public, but adopt the same or similar naming conventions as a
strong hint to developers to avoid using these in clients of these
classes. Again, I'd be very interested in hearing how others have dealt
with this issue.
Thanks.
-
Michael Brennan
Programmer/Analyst
Amgen Inc.
[1778 byte] By [
] at [2007-11-25 5:00:52]
Ok - Last one on this subject - then I am retiring.
I was not suggesting that these logger flags be used - I agree with
Roger they
are not supported and should not be used unless you know what you are
doing
and the full impact of using them.
The point I was making is that Forte have the ability to hide and
display
methods and attributes dependant on their privacy level. This type of
facility, which is what Michael wanted, IMHO should be made available to
developers, or a filter to hide and display private methods and
attributes -
without having to go into each attribute or method to see if its
private, or
use a crude marking approach.
Mark
>
> --
> Mark Potts
> SCAFFOLDS Product Manager
> Sage IT Partners
> --
> Voice : +1 415 392 7243 Ext. 520
>Fax : +1 415 391 3899
> <a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
> <a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
> --
Daniel Nguyen wrote:
> Hello,
>
> About flags given by Mark, beware : everything becomes public I think.
> In R3, you can use Interfaces. They may resolve a part of the problem by
> declaring the Interface of an object and having a seperated
> implementation class. But an attribute of an interface has also to point
> to a public attribute of the implementation object (same for a method).
> An implementation class can implement several interfaces and an
> interface can be implemented by several implemantation classes.
> Also, you can use multiple inheritence within interfaces and dynamic
> loading of the implementation classes at run-time (using dynamic load of
> librairies).
>
> Daniel Nguyen
>
> Mark S. Potts wrote:
> >
> > Michael
> >
> > You are very right to be a little disappointed with the browser
> > facilities in Forte - improvements has been promised for Release 4.0
> > but I believe the same was promised for Release 3.0.
> >
> > I have worked at several Forte sights where the Problem of Private and
> > Public methods and attributes has caused consternation. The '_' is about
> > the best option for implying Private / Protected.
> >
> > There are a couple of other issues though.
> >
> > Virtual attributes are a great way to define an interface - they have
> > accessor methods behind them to get and format internal/private state
> > information. However because of restrictions in the C++ code that is
> > compiled out of the forte code the Accessor methods that lie behind the
> > virtual attribute have to be public!
> >
> > Forte inherits in a strange way when attributes are private. A
> > superclass attribute that is made private is not accessible from any of
> > its subclasses - this means that many of what you would consider private
> > attributes in fact have to be public. Some would argue that this is
> > correct and that inheritance does break the pure rules of encapsulation
> > - but these people dont build applications! Although you can get round
> > this by having methods that are inherited its a workaround and not very
> > nice.
> >
> > Forte themselves actually do have a mechanism for hiding private methods
> > and attributes - If you turn on the logger flag ( Configuration C4 1-23
> > 255 - that's all of them - I cant remember the exact one ) you will be
> > allowed to see the private methods and attributes of the Forte classes.
> > This logger flag does lots of other things including altering settings
> > for the compiler - so be very careful when using it - Forte will not
> > support its use.
> >
> > What I am really saying is that yes use the underscore to show private
> > methods and use it to imply privacy even though, as in the two cases
> > above, you cannot make the attributes private.
> >
> > --
> > Mark Potts
> > SCAFFOLDS Product Manager
> > Sage IT Partners
> > --
> > Voice : +1 415 392 7243 Ext. 520
> >Fax : +1 415 391 3899
> > <a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
> > <a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
> > --
> >
> > Michael Brennan wrote:
> >
> > > I've been grappling with a couple of frustrations with Forte, and I'm
> > > interested in feedback from others on this list regarding approaches
> > > they may have adopted to address these.
> > >
> > > One is that in the Forte workshops there is no way to view only the
> > > public methods and attributes of a class (we're still using V2 here;
> > > I'm
> > > assuming that V3 has not changed this). While referring to appropriate
> > >
> > > technical documentation for a class is obviously important, I still
> > > find
> > > myself opening up classes in the workshops to inspect the methods and
> > > attributes available. (What I really want to see is an integrated
> > > class
> > > browser. I sure hope Forte is working on something like this, or will
> > > open up their development environment to support third-party
> > > extensions.
> > > But that's an aside.)
> > >
> > > A convention I just recently adopted in my work is to name private
> > > methods and attributes with a beginning underscore ("_"). That way the
> > >
> > > private elements are sorted to the top of the list and can be easily
> > > differentiated from public elements. I'm curious, though, whether
> > > others
> > > have adopted similar or different approaches.
> > >
> > > I've also felt a bit frustrated over the lack of support for protected
> > >
> > > attributes/methods for TOOL classes. This strikes me as a rather
> > > bothersome shortcoming. The only approach I can think of is to make
> > > such
> > > elements public, but adopt the same or similar naming conventions as a
> > >
> > > strong hint to developers to avoid using these in clients of these
> > > classes. Again, I'd be very interested in hearing how others have
> > > dealt
> > > with this issue.
> > >
> > > Thanks.
> > > -
> > > Michael Brennan
> > > Programmer/Analyst
> > > Amgen Inc.
> >
> > --
> > Mark Potts
> > SCAFFOLDS Product Manager
> > Sage IT Partners
> > --
> > Voice : +1 415 392 7243 Ext. 520
> >Fax : +1 415 391 3899
> > <a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
> > <a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
> > --
at 2007-6-29 9:19:40 >
At Mon, 10 Nov 1997 22:03:11 -0800 Stephen McHenry wrote:
>I share your desire for protected methods, but I have to disagree
>about protected attributes. Philosophically speaking, protected and
>public attributes are EVIL!! (I say "philosophically speaking"
>because, in the Forte environment, there are some valid reasons for
>using them based upon the visibility constraints of the language. In
>other languages, C++ and Java, for example, it's not even
>philosophically speaking - they're just *evil*!!)
Stephen,
I would be happy to agree with you, but I can't. Declaring ALL
attributes as private means that you need to provide mechanisms for
copying them in accessor methods, and for integrating them back into
container object, in mutator methods. It is a very good, defensive
way of programming, but it may require a lot of extra coding, and
this is not always absolutely necessary. What we are talking about is
the quality of code, and the quality is always expensive. Which car
is better: Mercedes or Ford? Anyone knows the answer, but not anyone
can afford Mercedes.
Regards,
Mikhail Schelkin
Conextions, Inc.
misha@conextions.com
at 2007-6-29 9:19:40 >
Mikhail
You wrote:
>I would be happy to agree with you, but I can't. Declaring ALL
>attributes as private means that you need to provide mechanisms for
>copying them in accessor methods, and for integrating them back into
>container object, in mutator methods. It is a very good, defensive
>way of programming, but it may require a lot of extra coding, and
>this is not always absolutely necessary. What we are talking about is
>the quality of code, and the quality is always expensive. Which car
>is better: Mercedes or Ford? Anyone knows the answer, but not anyone
>can afford Mercedes.
>
The cost depends on your development tools. If you generate business
classes for C++ and use inline functions for accessors/mutators there is
almost no extra cost.
David
========================================
David Vydra
Education Consultant
Forte Software, Inc.
dvydra@forte.com; phone: (510)986.3593
at 2007-6-29 9:19:40 >
>I've also felt a bit frustrated over the lack of support for protected
>attributes/methods for TOOL classes. This strikes me as a rather
>bothersome shortcoming. The only approach I can think of is to make such
>elements public, but adopt the same or similar naming conventions as a
>strong hint to developers to avoid using these in clients of these
>classes. Again, I'd be very interested in hearing how others have dealt
>with this issue.
I also have been frustrated by the lack of support for protected class
elements. Very frequently I've run into cases of methods that the
subclasses need to be able to call, but which should never be called by
the outside world. As you say, the only option is to make the methods
public and then carefully document their usage. I hadn't considered
using a particular naming scheme to distinguish them, but now that
you've mentioned it it does seem like a good idea.
Dale
Dale V. Georg
Indus Consultancy Services
dgeorg@indcon.com
at 2007-6-29 9:19:40 >
Our standard is to preface all private elements with "Prv." Perhaps
those elements that would in C++ be "protected" could be prefaced with
"Prot," or something similar to let developers know that although the
element is public, it should only be accessed by subclasses.
>-
>From:Dale V. Georg[SMTP:dvgeorg@ibm.net]
>Sent:November 12, 1997 03:51 PM
>To:kamranamin@yahoo.com; Michael Brennan
>Subject:Re: Private vs. protected, naming conventions etc.
>
>>I've also felt a bit frustrated over the lack of support for protected
>>attributes/methods for TOOL classes. This strikes me as a rather
>>bothersome shortcoming. The only approach I can think of is to make such
>>elements public, but adopt the same or similar naming conventions as a
>>strong hint to developers to avoid using these in clients of these
>>classes. Again, I'd be very interested in hearing how others have dealt
>>with this issue.
>
>I also have been frustrated by the lack of support for protected class
>elements. Very frequently I've run into cases of methods that the
>subclasses need to be able to call, but which should never be called by
>the outside world. As you say, the only option is to make the methods
>public and then carefully document their usage. I hadn't considered
>using a particular naming scheme to distinguish them, but now that
>you've mentioned it it does seem like a good idea.
>
>Dale
>
>Dale V. Georg
>Indus Consultancy Services
>dgeorg@indcon.com
>
>
at 2007-6-29 9:19:40 >
Michael
You are very right to be a little disappointed with the browser
facilities in Forte - improvements has been promised for Release 4.0
but I believe the same was promised for Release 3.0.
I have worked at several Forte sights where the Problem of Private and
Public methods and attributes has caused consternation. The '_' is about
the best option for implying Private / Protected.
There are a couple of other issues though.
Virtual attributes are a great way to define an interface - they have
accessor methods behind them to get and format internal/private state
information. However because of restrictions in the C++ code that is
compiled out of the forte code the Accessor methods that lie behind the
virtual attribute have to be public!
Forte inherits in a strange way when attributes are private. A
superclass attribute that is made private is not accessible from any of
its subclasses - this means that many of what you would consider private
attributes in fact have to be public. Some would argue that this is
correct and that inheritance does break the pure rules of encapsulation
- but these people dont build applications! Although you can get round
this by having methods that are inherited its a workaround and not very
nice.
Forte themselves actually do have a mechanism for hiding private methods
and attributes - If you turn on the logger flag ( Configuration C4 1-23
255 - that's all of them - I cant remember the exact one ) you will be
allowed to see the private methods and attributes of the Forte classes.
This logger flag does lots of other things including altering settings
for the compiler - so be very careful when using it - Forte will not
support its use.
What I am really saying is that yes use the underscore to show private
methods and use it to imply privacy even though, as in the two cases
above, you cannot make the attributes private.
--
Mark Potts
SCAFFOLDS Product Manager
Sage IT Partners
--
Voice : +1 415 392 7243 Ext. 520
Fax : +1 415 391 3899
<a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
<a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
--
Michael Brennan wrote:
> I've been grappling with a couple of frustrations with Forte, and I'm
> interested in feedback from others on this list regarding approaches
> they may have adopted to address these.
>
> One is that in the Forte workshops there is no way to view only the
> public methods and attributes of a class (we're still using V2 here;
> I'm
> assuming that V3 has not changed this). While referring to appropriate
>
> technical documentation for a class is obviously important, I still
> find
> myself opening up classes in the workshops to inspect the methods and
> attributes available. (What I really want to see is an integrated
> class
> browser. I sure hope Forte is working on something like this, or will
> open up their development environment to support third-party
> extensions.
> But that's an aside.)
>
> A convention I just recently adopted in my work is to name private
> methods and attributes with a beginning underscore ("_"). That way the
>
> private elements are sorted to the top of the list and can be easily
> differentiated from public elements. I'm curious, though, whether
> others
> have adopted similar or different approaches.
>
> I've also felt a bit frustrated over the lack of support for protected
>
> attributes/methods for TOOL classes. This strikes me as a rather
> bothersome shortcoming. The only approach I can think of is to make
> such
> elements public, but adopt the same or similar naming conventions as a
>
> strong hint to developers to avoid using these in clients of these
> classes. Again, I'd be very interested in hearing how others have
> dealt
> with this issue.
>
> Thanks.
> -
> Michael Brennan
> Programmer/Analyst
> Amgen Inc.
--
Mark Potts
SCAFFOLDS Product Manager
Sage IT Partners
--
Voice : +1 415 392 7243 Ext. 520
Fax : +1 415 391 3899
<a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
<a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
--
at 2007-6-29 9:19:40 >
Hi Michael,
I deal with these problems exactly the same way as you: begin
private methods/attributes names with underscore and set those
methods/attributes that should be protected, as public. Hope that in
the future versions of Forte (I work with R.2 ) these issues will
be addressed.
As we came to this point, I would also appreciate the support of
multiple inheritance, and providing the ability of subclassing for
all, not only chosen ones, native Forte classes.
Regards,
Mikhail Schelkin
Conextions, Inc.
misha@conextions.com
at 2007-6-29 9:19:40 >
At 04:01 PM 11/6/97 -0500, Mikhail Schelkin wrote:
>As we came to this point, I would also appreciate the support of
>multiple inheritance,
Check out interfaces in R3. I think this will cover most of the valid
needs for multiple inheritance for you.
=========================================================================
Thomas Mercer-Hursh, Ph.Demail: thomas@cintegrity.com
Computing Integrity, Inc.sales: 510-233-9329
550 Casey Drive - Cypress Pointsupport: 510-233-9327
Point Richmond, CA 94801-3751fax: 510-233-6950
at 2007-6-29 9:19:40 >
Hello,
About flags given by Mark, beware : everything becomes public I think.
In R3, you can use Interfaces. They may resolve a part of the problem by
declaring the Interface of an object and having a seperated
implementation class. But an attribute of an interface has also to point
to a public attribute of the implementation object (same for a method).
An implementation class can implement several interfaces and an
interface can be implemented by several implemantation classes.
Also, you can use multiple inheritence within interfaces and dynamic
loading of the implementation classes at run-time (using dynamic load of
librairies).
Daniel Nguyen
Mark S. Potts wrote:
>
> Michael
>
> You are very right to be a little disappointed with the browser
> facilities in Forte - improvements has been promised for Release 4.0
> but I believe the same was promised for Release 3.0.
>
> I have worked at several Forte sights where the Problem of Private and
> Public methods and attributes has caused consternation. The '_' is about
> the best option for implying Private / Protected.
>
> There are a couple of other issues though.
>
> Virtual attributes are a great way to define an interface - they have
> accessor methods behind them to get and format internal/private state
> information. However because of restrictions in the C++ code that is
> compiled out of the forte code the Accessor methods that lie behind the
> virtual attribute have to be public!
>
> Forte inherits in a strange way when attributes are private. A
> superclass attribute that is made private is not accessible from any of
> its subclasses - this means that many of what you would consider private
> attributes in fact have to be public. Some would argue that this is
> correct and that inheritance does break the pure rules of encapsulation
> - but these people dont build applications! Although you can get round
> this by having methods that are inherited its a workaround and not very
> nice.
>
> Forte themselves actually do have a mechanism for hiding private methods
> and attributes - If you turn on the logger flag ( Configuration C4 1-23
> 255 - that's all of them - I cant remember the exact one ) you will be
> allowed to see the private methods and attributes of the Forte classes.
> This logger flag does lots of other things including altering settings
> for the compiler - so be very careful when using it - Forte will not
> support its use.
>
> What I am really saying is that yes use the underscore to show private
> methods and use it to imply privacy even though, as in the two cases
> above, you cannot make the attributes private.
>
> --
> Mark Potts
> SCAFFOLDS Product Manager
> Sage IT Partners
> --
> Voice : +1 415 392 7243 Ext. 520
>Fax : +1 415 391 3899
> <a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
> <a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
> --
>
> Michael Brennan wrote:
>
> > I've been grappling with a couple of frustrations with Forte, and I'm
> > interested in feedback from others on this list regarding approaches
> > they may have adopted to address these.
> >
> > One is that in the Forte workshops there is no way to view only the
> > public methods and attributes of a class (we're still using V2 here;
> > I'm
> > assuming that V3 has not changed this). While referring to appropriate
> >
> > technical documentation for a class is obviously important, I still
> > find
> > myself opening up classes in the workshops to inspect the methods and
> > attributes available. (What I really want to see is an integrated
> > class
> > browser. I sure hope Forte is working on something like this, or will
> > open up their development environment to support third-party
> > extensions.
> > But that's an aside.)
> >
> > A convention I just recently adopted in my work is to name private
> > methods and attributes with a beginning underscore ("_"). That way the
> >
> > private elements are sorted to the top of the list and can be easily
> > differentiated from public elements. I'm curious, though, whether
> > others
> > have adopted similar or different approaches.
> >
> > I've also felt a bit frustrated over the lack of support for protected
> >
> > attributes/methods for TOOL classes. This strikes me as a rather
> > bothersome shortcoming. The only approach I can think of is to make
> > such
> > elements public, but adopt the same or similar naming conventions as a
> >
> > strong hint to developers to avoid using these in clients of these
> > classes. Again, I'd be very interested in hearing how others have
> > dealt
> > with this issue.
> >
> > Thanks.
> > -
> > Michael Brennan
> > Programmer/Analyst
> > Amgen Inc.
>
> --
> Mark Potts
> SCAFFOLDS Product Manager
> Sage IT Partners
> --
> Voice : +1 415 392 7243 Ext. 520
>Fax : +1 415 391 3899
> <a href=
"mailto:mark.potts@sageit.com">mailto:mark.potts@sageit.com</a>
> <a href=
"http://www.sageitpartners.com">http://www.sageitpartners.com</a>
> --
at 2007-6-29 9:19:40 >
Michael,
I agree with Daniel Nguyen. We are using interfaces to provide public
definitions of our classes. We place our public interfaces in a
seperate project from our implementation. We also go one step further
by providing an internal (or protected) interface as well. This way
those who are developing inside the library/sub-system know what others
(both internal and external) expect of their code.
One note about Forte's implementation of interfaces (no pun intended).
Forte has implemented interfaces as classes without implementations.
This causes a problem (at least in my opinion) ... interfaces have
other interfaces as superclasses (and as we all know ... there can be
only one superclass) ... interfaces cannot implement other interfaces
(at least they cannot be defined as implementing - only inheriting).
So ... if you are listening, Forte ... I am putting in my vote for
multiple interface implentation by interfaces.
at 2007-6-29 9:19:40 >
I sent this once before, but the list seemed to be having trouble late last
week. If you get two copies of it... my apologies.
-
-
OK, I couldn't resist joining the fray...
At 10:56 AM 11/6/97 -0800, Michael Brennan wrote:
>
>A convention I just recently adopted in my work is to name private
>methods and attributes with a beginning underscore ("_"). That way the
>private elements are sorted to the top of the list and can be easily
>differentiated from public elements. I'm curious, though, whether others
>have adopted similar or different approaches.
You might even designate a single character before the underscore to denote
that, just in case some environment (CORBA) doesn't like the "_". You could
make it something like "Q" or "Z" or something that wouldn't normally be
used alone at the start of a name.
>
>I've also felt a bit frustrated over the lack of support for protected
>attributes/methods for TOOL classes. This strikes me as a rather
>bothersome shortcoming. The only approach I can think of is to make such
>elements public, but adopt the same or similar naming conventions as a
>strong hint to developers to avoid using these in clients of these
>classes.
I share your desire for protected methods, but I have to disagree about
protected attributes. Philosophically speaking, protected and public
attributes are EVIL!! (I say "philosophically speaking" because, in the
Forte environment, there are some valid reasons for using them based upon
the visibility constraints of the language. In other languages, C++ and
Java, for example, it's not even philosophically speaking - they're just
*evil*!!)
One of the principal reasons for adopting the object paradigm is to
*tightly* control the impact of change - to provide good boundaries of
encapsulation that change does not ripple beyond. If you think about it,
one of the measures of the success of a superclass is the number of
subclasses that it has (especially for a good dabstract interface). This
says you have very nicely captured the semantics of the application domain
in the interface of the superclass. So, let's imagine a superclass with
protected attributes that are used by each of its 100 subclasses (probably
more than you would have, but I'm illustrating my point - incidentally, I'm
*not* talking about a hierarchy 100 deep; I'm talking about 100 subclasses
that are all direct decendants of the superclass). Now you go and change
one of the attributes. You must go look at all 100 subclasses to determine
the impact of change. This is exactly the kind of thing the object paradigm
was designed to eliminate.
Protected methods, on the other hand, would be nice.
And At 12:06 PM 11/6/97 -0800, Mark S. Potts wrote:
>
>Forte inherits in a strange way when attributes are private. A
>superclass attribute that is made private is not accessible from any of
>its subclasses - this means that many of what you would consider private
>attributes in fact have to be public.
Well, the definition of private means "not visible outside of the class
where it is defined". I find it useful to think of the level of visibility
the same as secrets. There are things that are not really secrets at all -
it's ok if anyone knows them ("My name is Stephen"). These are public.
Then, there are things that it's ok if my family knows, but I don't want
the world to know - familial secrets, if you will ("I belch at the dinner
table when I'm at home"). These are visible to descendant classes and we
call them protected. Finally, there are things we don't want *anyone* else
to know, no matter who they are ("I poisoned my mother-in-law"). These are
private. We don't want anyone outside of ourselves to know these things.
These are the classic definitions of public, protected and private (perhaps
classic only because C++ defined them that way and everyone else just
copied what it meant).
Private attributes are not meant to be inherited by their subclasses.
That's why they're private. And, yes, I would argue that that is completely
correct. What you want, if you want them to be visible to subclasses, is
"protected". Now, Forte doesn't support protected, but that's a different
arguement - perhaps even an enhancement request.
We also should not confuse what we need to do in a language/environment
with what good OO principles are. For example, good OO design principles
state that you do not have public or protected attributes. Period! You
access them via accessors and mutators defined on the appropriate class.
Now, in some environments, this will not give you the performance you need,
so you open things up a bit. But, you shouldn't convince yourself that
doing this is the ideal design, just that it was necessary for performance.
The real problem here is that the performance of accessor and mutator
functions is not fast enough. That's why we open it up. *Not* because it is
good design. The proper way to fix the problem is to make accessors and
mutators fast enough so that they can be used (C++, for example, does this
with "inline" - not that C++ is my favorite language, it's not. But they
have fixed this one area nicely.)
>Some would argue that this is correct and that inheritance does break the
pure rules
> of encapsulation
I don't think inheritance, properly handled (and Forte *does* properly
handle it) breaks any rules of encapsulation. I would argure that the way
they treat private attributes is quite correct.
> - but these people dont build applications!
Hmmm... let's see... started building OO applications in 1985 (and building
them ever since) in complex application domains like CAD/CAM/CAE, Air
Traffic Control, Graphics/Imaging, Telecommunications, e-commerce,
entertainment,... ...wrote (and teach) the Forte OO Analysis and Design
course.
I guess you're right. I don't build applications. I build robust,
maintainable, extendable applications. ( ;-)...nudge, nudge!)
Stephen
at 2007-6-29 9:19:40 >
Mark Potts. wrote:
>
> You are quite correct about C++ tools, but in our experience of IDL
> files the compiler complains about anything that starts with a non
> alphabetic character, which '_' double or single is.
Ah, I see. It is the IDL compiler, not Forte, that has problems with
this.
Is it safe to use, though, the '_' character for private
attributes/methods? I have not worked with CORBA, yet, but I would
presume that the IDL is generated only for the public
attributes/methods. Is that a correct assumption? If so, would it be
safe to say, then, that it is OK to start the names of private
attributes/methods with '_', but it should be avoided for public
attributes/methods? (That destroys my strategy for "protected"
attributes/methods, but it would be nice to at least use this mechanism
for private attributes/methods.)
-
Michael Brennan
Programmer/Analyst
Amgen Inc.
at 2007-6-29 9:19:40 >
Mark Potts. wrote:
>
> The point I was making is that Forte have the ability to hide and
> display
> methods and attributes dependant on their privacy level. This type of
> facility, which is what Michael wanted, IMHO should be made available to
> developers, or a filter to hide and display private methods and
> attributes -
> without having to go into each attribute or method to see if its
> private, or
> use a crude marking approach.
Yes, I think this would be very useful to have a supported facility for
doing this. That's really what I want. Thanks for your remarks, Mark.
(And thanks to all the others, too, who've offered helpful remarks on
this.)
I'm also very concerned about a remark you made in a previous message:
> As I understand it, the use of '_' prefix leads to problems generating
> IDL.
> I beleive the use of the '_' cuases the comile to fail on the IDL File.
I wonder if anyone can elaborate on this. We are not currently doing any
CORBA work, but it is something we are very interested in and are likely
to be exploring in the near future. I would hate to adopt a naming
convention now in my work that could create problems for us later as we
try to make Forte service objects available to CORBA clients. Can anyone
confirm, deny, or elaborate on this? Some C++ tools I've used in the
past reserve double underscores for their own use, but explicitly use a
double underscore to allow the developer to use single underscores
without having to worry about conflicts. It seems like this could be a
nice enhancement to Forte, too, if there is currently a problem
generating IDL for classes that use a leading underscore for
attribute/method names.
-
Michael Brennan
Programmer/Analyst
Amgen Inc.
at 2007-6-29 9:19:40 >
