Re: the Java Lang will support Properties in Futuere?

On Sun, 16 Nov 2008 17:19:44 -0800, Mark Space <markspace@xxxxxxxxxxxxx> wrote:

Peter Duniho wrote:

Because it's what everyone has been using. There are huge volumes of code that depend on the current property idiom and it pretty much works fine.
Personally, I like language-supported properties. But as long as people follow standard conventions, you can get nearly all the benefit of baked-in properties using regular methods. One of the biggest


Reading this thread, I think this attitude is reversed. Sure, this "hides" from the user whether a is a property or field:

foo.a = 1;
int a = foo.a;

But what if "a" isn't a property?

Huh? Then you don't implement it as a property.

public void setA( int i ) {
outputStream.write( i );
outputStream.flush();
}

public int getA() {
// read from file or DB...
}

How does this work when the expected syntax is .propertyName?

Huh? Is "A" (or "a") a property or not? If it's a property (and there's nothing about the code you posted that insists that it's not), then you use the property syntax. If it's not a property, then you use the method syntax.

I think using the . syntax forces you to distinguish between "real" properties that are supported by the baked-in language property feature, and pseudo-properties that must be supported by method calls.

Huh? Why is being forced to distinguish between a property and something that's simply a method call a bad thing? And why do you seem to have the impression that having language support for a property is in some way mutually exclusive with a _real_ property "that must be supported by method calls" (I have no idea what a "pseudo-property" is...either it's a property or it's not).

Using the method call syntax for both provides the better abstraction, imo.

I'm really at a loss as to what you mean. Most of your post didn't make sense to me, and what I thought I understood seems to me to argue very much in favor of having language support for properties. But you otherwise seem against the idea, which means what you wrote was probably not intended to mean what I read it to mean (that is, you probably didn't mean to argue in favor of language support for properties).

I definitely disagree that having no language support for an abstraction like a property provides _better_ abstraction. That seems like an obvious self-contradiction to me. If it's an abstraction, then having the language support the abstraction has to be better than not. Saying an abstraction is better provided for when the language leaves the provision for that abstraction out makes no sense to me.

Pete
.

Relevant Pages

  • Re: RPN maps to basic mathematic expressions nicely
    ... fact that Factor is postfix means that it is really only an assembler ... The fact that C-style syntax is the most popular ... reasonable level of abstraction, but are ugly and a hassle to work with ... HTTP client and RSS/XML parsing libraries, since any decent language ...
    (comp.lang.forth)
  • Re: Word 2003 - different pagination on different documents
    ... I had the users check on any installed or turn-on language support. ... our problem doc to my own Normal (and clicking the “Automatically ... Has the paragraph been given a negative right ...
    (microsoft.public.word.docmanagement)
  • Re: multiple language support: dialog-boxes
    ... I`ve a sdi application where I want to add multiple language support. ... using a simple std::map to map language abbreviations to DLL handles might ... Both have the same resources as ...
    (microsoft.public.vc.mfc)
  • Help regarding MUI
    ... "Regional and Language support" component lists what are the ... an option to "Enable multilanguage user interface for this component ...
    (microsoft.public.windowsxp.embedded)
  • Re: copy contructor
    ... > least language support I've ever seen for doing OO - it doesn't even have ... if you really want to do OO, use a different language. ... and an (inheriting) client class may have to override all of them. ... Usually that only means to define a few field accessors in the usual way, ...
    (comp.lang.perl.misc)