Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: News for Java?

Reply
Thread Tools

Re: News for Java?

 
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-05-2011
On 11-01-05 12:59 PM, Sherm Pendley wrote:
> Arved Sandstrom<(E-Mail Removed)> writes:
>
>> It's obviously not black and white. It's a question of what are you
>> using the getters and setters for. There's way too much code out there
>> that extracts fine-grained state from objects using getters, then does
>> logic using all that state, when it should have been the object itself
>> that was asked to do it, and provide the final result.

>
> So really, it's breaking encapsulation you dislike, and accessors just
> happen to be a common means of doing so.
>
> sherm--
>

Yes, if we use the definition of encapsulation as hiding the internal
representation of an object, and restricting access to it. There are
weaker definitions (generally focusing on simply the grouping of data
with the methods that operate on the data) and under those definitions a
bunch of accessors is not necessarily breaking encapsulation at all. But
I prefer the strong definition.

The concern I have when I see code that supplies getters and setters for
practically every member field in a class, and this kind of code is not
rare, is that the developer hasn't actually (usually in my experience)
analyzed the class to understand what the valid and consistent states
are. And it's practically guaranteed that a proliferation of accessors
will enable the placing of instances into inconsistent states.

AHS
 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      01-05-2011
On 11-01-05 12:15 PM, Peter Duniho wrote:
> On 1/5/11 2:33 AM, Arved Sandstrom wrote:
>> There are no real problems having setters??? Come on, Arne, are you just
>> being rambunctious these past few or what? Leaving aside getters
>> completely (and all the real-world problems associated with over-use of
>> those), every setter on a class introduces a vulnerability: it's an
>> additional worry when you reason about what external code is modifying
>> instances of that class. [...]

>
> Red herring.
>
> You guys can debate the question of abuse of setters 'til the cows come
> home. It will never have any relevance to the question of
> language-supported properties. If a programmer is likely to overdo it
> with the setters with language-supported properties, they are just going
> to overdo it without language-supported properties too.

[ SNIP ]

I don't believe I threw a red herring out there. When I say accessor I
really mean getter/setter/property/accessible-member-field. I couldn't
care less what language-specific mechanism is used to afford access to
internal state of objects. I agree - if a programmer is ill-disciplined
in this regard then the specific semantics hardly matter.

AHS
 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      01-06-2011
On 04-01-2011 23:51, Mike Schilling wrote:
> "Peter Duniho" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) acquisition...
>> Even Java has at least one place I know of where the JDK API requires
>> you to pass an array so that the method can return more than one value
>> and do so without allocating a new object each call.

>
> It would be neater (IMHO) for InputStream.get() to be defined
>
> boolean get(out char c)
>
> than
>
> int get()
>
> with a special return value that means "there wasn't one".


Java inherited some stuff from C in this aspect.

Arne

PS: I assume that you mean byte not char.
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      01-06-2011
On 05-01-2011 15:54, Tom Anderson wrote:
> On Tue, 4 Jan 2011, Mike Schilling wrote:
>> "Peter Duniho" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) acquisition...
>>
>>> Even Java has at least one place I know of where the JDK API requires
>>> you to pass an array so that the method can return more than one
>>> value and do so without allocating a new object each call.

>>
>> It would be neater (IMHO) for InputStream.get() to be defined
>>
>> boolean get(out char c)
>>
>> than
>>
>> int get()
>>
>> with a special return value that means "there wasn't one".

>
> Even better:
>
> byte get() throws EndOfFileException
>
> Although i know that many would not agree with me on that.


It is a nicer API.

But I am not sure that EOF qualifies as being exceptional.

Arne
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      01-06-2011
On 05-01-2011 15:47, Tom Anderson wrote:
> On Tue, 4 Jan 2011, Peter Duniho wrote:
>> But Java doesn't have that feature either.

>
> That too. Not enough Dutchmen at Sun, obviously.


????

Arne

 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      01-06-2011


"Tom Anderson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) rth.li...
> On Tue, 4 Jan 2011, Mike Schilling wrote:
>
>> "Peter Duniho" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed) acquisition...
>>
>>> Even Java has at least one place I know of where the JDK API requires
>>> you to pass an array so that the method can return more than one value
>>> and do so without allocating a new object each call.

>>
>> It would be neater (IMHO) for InputStream.get() to be defined
>>
>> boolean get(out char c)
>>
>> than
>>
>> int get()
>>
>> with a special return value that means "there wasn't one".

>
> Even better:
>
> byte get() throws EndOfFileException
>
> Although i know that many would not agree with me on that.


Me for one. I don't expect a stream to be of infinite length, and
exceptions are for *un*expected circumstances.

 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      01-06-2011


"Arne Vajhj" <(E-Mail Removed)> wrote in message
news:4d250b12$0$23758$(E-Mail Removed)...
> On 05-01-2011 15:54, Tom Anderson wrote:
>> On Tue, 4 Jan 2011, Mike Schilling wrote:
>>> "Peter Duniho" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed) acquisition...
>>>
>>>> Even Java has at least one place I know of where the JDK API requires
>>>> you to pass an array so that the method can return more than one
>>>> value and do so without allocating a new object each call.
>>>
>>> It would be neater (IMHO) for InputStream.get() to be defined
>>>
>>> boolean get(out char c)
>>>
>>> than
>>>
>>> int get()
>>>
>>> with a special return value that means "there wasn't one".

>>
>> Even better:
>>
>> byte get() throws EndOfFileException
>>
>> Although i know that many would not agree with me on that.

>
> It is a nicer API.


Not if every loop requires a catch block, it isn't.


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-06-2011
On Jan 5, 11:15*am, Peter Duniho <(E-Mail Removed)> wrote:
> On 1/5/11 2:33 AM, Arved Sandstrom wrote:
>
> > There are no real problems having setters??? Come on, Arne, are you just
> > being rambunctious these past few or what? Leaving aside getters
> > completely (and all the real-world problems associated with over-use of
> > those), every setter on a class introduces a vulnerability: it's an
> > additional worry when you reason about what external code is modifying
> > instances of that class. *[...]

>
> Red herring.
>
> You guys can debate the question of abuse of setters 'til the cows come
> home. *It will never have any relevance to the question of
> language-supported properties. *If a programmer is likely to overdo it
> with the setters with language-supported properties, they are just going
> to overdo it without language-supported properties too.
>
> After all, it's not that Java doesn't have "properties" per se today.
> It's just that the syntax is indistinguishable from the syntax for
> methods, other than following some simple conventions regarding naming.
>
> So, if I'm a programmer who would write this:
>
> * *private int _value;
> * *public int Value
> * *{
> * * *get { return _value; }
> * * *set { _value = value; }
> * *}
>
> Instead of this:
>
> * *private int _value;
> * *public int Value
> * *{
> * * *get { return _value; }
> * *}
>
> Then I'm also a programmer who would write this:
>
> * *private int _value;
> * *public int getValue()
> * *{
> * * *return _value;
> * *}
>
> * *public void setValue(int value)
> * *{
> * * *_value = value;
> * *}
>
> Instead of this:
>
> * *private int _value;
> * *public int getValue()
> * *{
> * * *return _value;
> * *}
>
> Language-supported properties neither encourages nor discourages that
> kind of program.
>
> Note also that, at least in the C# implementation (other languages may
> have similar rules), you can write this:
>
> * *public int Value { get; private set; }
>


Of course, in Java you can write this:

public class Foo
{
private Bar bar;
...
public Bar getBar() { return bar; }
/* p-p */ void setBar( Bar b ) { bar = b; }
}

You could use 'protected' instead of default access for the setter if
needed.

> That declares the backing field, and both accessor methods all in one
> line of code. *The setter is private, thus allowing the property to be
> read-only to the public. *Typically, the declaring class would use the
> private setter in the constructor only, and of course that would be de
> rigueur for immutable types.
>


Naturally Java is less terse.

--
Lew
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      01-06-2011
On Wed, 5 Jan 2011, Stefan Ram wrote:

> Tom Anderson <(E-Mail Removed)> writes:
>> byte get() throws EndOfFileException

>
> Or, java.util.Iterator<java.lang.Byte>:
> boolean hasNext(), java.lang.Byte next().


Or that. How would we extend that to be able to read many bytes at once?
Presumably something like:

interface BulkIterator<E> extends Iterator<E> {
void addNextTo(Collection<E> c, int maxCount);
void addNextTo(Collection<E> c);
}

And then cross your fingers that JVM implementors can make that suitably
fast for common kinds of recipient collections.

tom

--
HATE THIS SONG ITS TERRIBLE! SHES ANNOYIN ASWELL AND I DONT LIKE HER
!!!!!!!!!! ;( -- songlover
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      01-06-2011
On Wed, 5 Jan 2011, Arne Vajhj wrote:

> On 05-01-2011 15:47, Tom Anderson wrote:
>> On Tue, 4 Jan 2011, Peter Duniho wrote:
>>> But Java doesn't have that feature either.

>>
>> That too. Not enough Dutchmen at Sun, obviously.

>
> ????


I assume that was a reference to a Python feature whose origin i impute to
Guido van Rossum. If you hadn't snipped off the preceding text, i could
probably tell you which one.

tom

--
HATE THIS SONG ITS TERRIBLE! SHES ANNOYIN ASWELL AND I DONT LIKE HER
!!!!!!!!!! ;( -- songlover
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for a breaking news rss feed that really contains breaking news Amy XML 0 02-22-2005 06:31 PM
OT: Job interview, Good news, Bad news LnkWizard MCSE 110 09-22-2004 03:33 PM
Cant get a <div> to display news from Cute News. Talimore HTML 4 07-18-2004 01:49 AM
Increasing news results in the moreover news feeds Paul Briggs HTML 1 06-08-2004 09:12 AM



Advertisments