All -
My only reservations concerned expanding the PRIVATE keyword and the
surprise factor for a developer when existing code got modified. It was
the reason I suggested the addition of a new keyword for this kind of
scoping.
But if everyone feels like the surprise factor is negligible, then
On Mon, Dec 15, 2008 at 4:25 AM, Rick McGuire object.r...@gmail.com wrote:
btw, I still have a patch file to implement this as a redefinition of
the PRIVATE keyword. It's a fairly small change. Doing this as a
different keyword is a little more work.
Over time, as I thought about this,
Hi y'all
It's my opinion, though not being in any offical capacity, that one
should never break existing behaviour. Therefore loosening the meaning
of PRIVATE doesn't seem right to me. I would suggest an additional
keyword on the PRIVATE declaration, instead of having to invent a new
No, this was never implemented. There seemed to be quite a bit of
resistance toward doing this, and no concensus on whether this should
be done by changing the rules for PRIVATE or using a new keyword. I'm
fine with either, I think.
Rick
On Sun, Dec 14, 2008 at 5:50 PM, Mark Miesfeld
The classic example of a place where something like this is needed is
in a comparison method. Frequently, a comparison between two
instances of a class requires data that should remain private to the
instances, but because of the private scoping rules, it becomes
necessary to expose that data as
Rick -
I am not so sure I am in favor of this but I don't have any specific
rebuttals at the moment. I will get back to you.
Thanks,
W. David Ashley
IBM Systems and Technology Group Lab Services
Open Object Rexx Team
Mobile Phone: 512-289-7506
Gee, and your GTK work was one place where it definitely applied too :-)
Rick
On Thu, Aug 14, 2008 at 11:25 AM, David Ashley [EMAIL PROTECTED] wrote:
Rick -
I am not so sure I am in favor of this but I don't have any specific
rebuttals at the moment. I will get back to you.
Thanks,
W.
On Thu, Aug 14, 2008 at 8:25 AM, David Ashley [EMAIL PROTECTED] wrote:
I am not so sure I am in favor of this but I don't have any specific
rebuttals at the moment. I will get back to you.
If David is not sure about this, then I'm more inclined to say I would
prefer that PRIVATE not be
On Thu, Aug 14, 2008 at 9:28 AM, Rick McGuire [EMAIL PROTECTED] wrote:
On Thu, Aug 14, 2008 at 12:10 PM, Mark Miesfeld [EMAIL PROTECTED] wrote:
The rebuttals that I thought of are:
1.) Changing the behavior of PRIVATE runs the risk, maybe slight, of
breaking someones existing programs.
I've considered that also, but introduces a whole new paradigm to the
object model vs. relaxing some restrictions in an already existing
concept. This essentially is a friend concept, but the friendship
list is limited to just myself.
Rick
On Thu, Aug 14, 2008 at 1:28 PM, Jack Woehr [EMAIL
Rick McGuire wrote:
I've considered that also, but introduces a whole new paradigm to the
object model vs. relaxing some restrictions in an already existing
concept. This essentially is a friend concept, but the friendship
list is limited to just myself.
Well, you could still give a
There's one feature of other languages like C++ and Java I really miss
in ooRexx. In Java, an instance of a class can access non-public
methods and fields of another instance of the same class. ooRexx has
PRIVATE methods, but access to those methods is limited to calls from
the within the same
12 matches
Mail list logo
