Re: Draft Proposal: Attributes: "public" vs. "private"
On Friday, October 4, 2002, at 07:39 PM, Michael Lazzaro wrote: [SNIP] > Definition: "private": > > A "private" attribute is an attribute whose scope is restricted such > that > it may be accessed only within the class in which it has been > declared. > It is not available to subclasses, nor to code outside the class. > [But see an alternative possible definition, below] [SNIP] > Note that an alternate definition of "private" is often used, as > follows: > > A "private" attribute is an attribute whose scope is restricted such > that > it may be accessed only within the class in which it has been > declared, > OR WITHIN ANY CLASS THAT INHERITS FROM THAT CLASS. I'll agree with that. > > Many programmers in fact expect "private" attributes to work this way. > Some languages recognize all three definitions, calling the above > "protected" access. I'm not sure what languages you are referring to specifically, but if you are including JAVA in that list then you are incorrect because JAVA allows protected members to be accessed from within any class within the same package as well, wether it is a subclass or not. > > The notion of "public" attributes is controversial within the OO > world. In general, public attributes may be better implemented as > public accessor methods to an attribute that remains private. (It > typically depends on how the language in question uses "attributes", > and whether the language treats attributes and methods in a roughly > symmetric fashion.) It depends on how you want to encapsulate your implementation details. One of the weakest points of PERL5 is data encapsulation (IMHO). A respectable language should, at its core, enforce a simple, straight forward notion of scoping. So while languages may differ on the types of scoping they offer, the rules and implementations surrounding them should be concise and not open for interpretation. Encapsulation in "OO PERL5" provides a multitude of opportunity for people to go out and kill themselves, and anyone else using their code in grand array of variations. Each variation producing its own unique and ghastly crime scene photo op. You have at your disposal such ghastly choices of mayhem as: Encapsulation via closures Tie::SecureHash Encapsulation via scalars...one of my personal masochistic favorites Something as basic as scoping/encapsulation should not be something left up to the programmer to create an implementation of. Nor, should they have the ability to create their own version of it. I'm all for having 16 ways to approach a problem but not when it comes to fundamental language aspects. That degrades the robustness of the language. Two words, 'access modifiers'. :-) OK, so back to the original topic of this thread. I like Java's notion of things. Attributes and methods are "package private" by default. Which means they are only visible to package they are in (slightly more restrictive then protected). Java also offers the following access modifiers: private - no visibility outside of the class protected - classes in the package and subclasses inside or outside the package public - all classes -Noah
Re: Draft Proposal: Attributes: "public" vs. "private"
> >> Note that an alternate definition of "private" is often used, as >> follows: >> >> A "private" attribute is an attribute whose scope is restricted such >> that >> it may be accessed only within the class in which it has been >> declared, >> OR WITHIN ANY CLASS THAT INHERITS FROM THAT CLASS. > > I'll agree with that. > ACK! After re-reading this I about puked. No, that notion of private would not be something I'd agree with :-) That's more like protected. -Noah
Re: RFC: [] as the solitary list constructor
On Saturday, October 5, 2002, at 09:33 PM, Larry Wall wrote: > > > : Additionally, parentheses have one inconsistency which brackets do > not: > : This is the following case, already shown on perl6-language: > : > : $a = ();# $a is a list reference with 0 elements > : $a = (10); # $a is the scalar 10 > : $a = (10, 20); # $a is a list reference with 2 elements > : # ... > : > : If the ability to construct lists with parentheses is removed, so is > this > : inconsistency. > > I don't think that's an important inconsistency. [SNIP] > > : This has the added benefit that there is a significant > : visual clue about when a list is being tossed around. This doesn't > break > : any convenience, just changes the look of it: > : > : # Perl 6# Perl 5 > : [$a, $b] ^= [$b, $a]; # ($a, $b) = ($b, $a) > : print *[$a=$b],"\n";# print(($a=$b), "\n"); > : push @a: *[1,2,3]; # push @a, (1,2,3); > : push @a: [1,2,3]; # push @a, [1,2,3]; > > I'd rather they just work the way people expect from Perl 5. Requiring > people to say *[1,2,3] when they could say 1,2,3 is needless > obfuscation. I think needless obfuscation is treating $a = (10); as a scalar instead of a list reference containing one item when the rest of the the $a = () are list references. -Noah
Re: Interfaces
On Monday, September 30, 2002, at 08:23 PM, Michael G Schwern wrote: > OTOH, Java interfaces have a loophole which is considered a design > mistake. > An interface can declare some parts of the interface optional and then > implementors can decide if they want to implement it or not. The > upshot > being that if you use a subclass in Java you can't rely on the optional > parts being there. > Say what?!? I don't think so. If a JAVA class which implements an interface does not declare all of the methods of the interface then that class will be abstract and you won't be able to instantiate a concrete instance of it. You are guaranteed that any concrete instance of a class which implements an interface will contain ALL methods defined by the interface. -Noah
Re: RFC: [] as the solitary list constructor
On Sunday, October 6, 2002, at 01:50 AM, Brent Dax wrote: > Parens don't construct lists EVER! They only group elements > syntactically. One common use of parens is to surround a > comma-separated list, but the *commas* are creating the list, *not* the > parens! > Following this rule would mean that $a = (); # $a is a list reference with 0 elements should not be a list reference at all and would appear inconsistent. -Noah
Re: Interfaces
On Sunday, October 6, 2002, at 06:17 PM, Daniel B. Boorstein wrote:
[SNIP]
> I think there may be some confusion here. In java, there's no special
> syntax
> to declare a method an optional part of the interface. All concrete
> classes
> that implement the Collection interface still must define full-bodied
> C methods. It just so happens that by convention
> some
> classes simply throw an UnsupportedOperationException, perhaps like so:
>
> public class MyStaticCollection implements Collection {
> ...
> public boolean add (Object element) {
> throw new UnsupportedOperationException("add not supported");
> }
> ...
> }
Yes, this is true and is a common way to stub out methods you may
choose not to provide functionality for. For example, your code
implements a JDK 1.2 interface, then you subsequently switch to the 1.4
VM implementation for which that interface's API has changed and there
are now 14 more methods to be implemented for which you don't care
about :-) You still need to provide the method signatures in your
concrete class, but as in your example above you can throw an
UnsupportedOperationException within that method. Or as Michael
pointed out in the Collections interface, the add() method of a
read-only Collection implementation will throw an
UnsupportedOperationException.
I wouldn't call it a dirty little secret as Michael put it :-). This
is the right thing to do within the context of a contract. The contract
does not guarantee that method functionality implemented by a concrete
class does exactly a certain thing a certain way ( I'd like to see the
language that does!). It only guarantees return type, optional
parameters to accept and any CHECKED exceptions that need be thrown
(and _importantly_, caught by the invoker), not actually what goes on
in the method. If it did it wouldn't be an interface :-) Now, an
UnsuppoertedOperationException is an UNCHECKED (subclass of
RuntimeException) exception.
The weakness if any lies here. It would be nice for the compiler to
tell me that I've invoked a method which is going to throw that
exception, so I would know that I used a method that I probably
shouldn't be using before it actually gets tapped at runtime which is
too late and goes *boom*.
-Noah
