Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24716 > unrolled thread

Interface with implied Constructor

Back to article view | Back to comp.lang.java.programmer

Contents

  Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-09 18:41 +0800
    Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-09 04:08 -0700
      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 06:46 +0800
        Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-09 21:08 -0400
        Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-11 19:11 -0700
          Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-14 17:53 +0200
            Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-15 08:58 -0700
              Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-15 10:57 -0700
                [OT] Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-15 14:13 -0400
                  Re: [OT] Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-15 12:58 -0700
              Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-15 20:45 +0200
        Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-14 18:03 +0200
          Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 23:21 -0300
            Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-19 12:38 -0700
              Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 17:56 -0300
                Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-22 12:39 -0700
                  Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-22 16:02 -0400
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-22 18:08 -0300
                    Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-23 14:32 -0700
                      Re: Interface with implied Constructor Jim Gibson <jimsgibson@gmail.com> - 2013-07-23 14:43 -0700
                        Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-24 13:27 -0700
                          Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-24 18:20 -0300
                            Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-26 00:03 +0200
                          Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-24 21:18 +0000
                            Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-24 17:42 -0400
                      Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-23 18:19 -0400
                        Re: Interface with implied Constructor Gene Wirchenko <genew@telus.net> - 2013-07-24 13:31 -0700
                      Re: Interface with implied Constructor Steven Simpson <ss@domain.invalid> - 2013-07-27 04:06 +0100
              Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-19 21:21 +0000
                Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 18:56 -0300
                  Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-19 18:10 -0400
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-19 20:46 -0300
                      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 12:42 +0800
                        Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-20 09:08 -0300
                        Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 09:08 -0400
                Re: Interface with implied Constructor Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-07-19 19:20 -0700
                  Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-19 20:11 -0700
                    Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-20 12:26 +0800
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-20 09:38 -0300
                Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 19:46 +0200
                  Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-20 19:12 +0000
                    Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 17:12 -0400
                      Re: Interface with implied Constructor Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-20 21:18 +0000
                        Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-21 12:13 +0200
                    Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 16:18 -0300
                      Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-21 13:45 -0700
                      Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-21 16:58 -0400
                        Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 21:19 -0300
            Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 20:09 +0200
              Re: Interface with implied Constructor Robert Klemme <shortcutter@googlemail.com> - 2013-07-20 20:21 +0200
              Re: Interface with implied Constructor Joerg Meier <joergmmeier@arcor.de> - 2013-07-20 23:17 +0200
                Re: Interface with implied Constructor Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-20 17:32 -0400
                  Re: Interface with implied Constructor Joerg Meier <joergmmeier@arcor.de> - 2013-07-21 00:10 +0200
              Re: Interface with implied Constructor Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-21 17:53 -0300
    Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-09 18:13 -0700
      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 18:03 +0800
        Re: Interface with implied Constructor markspace <markspace@nospam.nospam> - 2013-07-10 08:41 -0700
          Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-11 06:53 +0800
    Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-09 21:41 -0700
      Re: Interface with implied Constructor Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-07-10 17:55 +0800
      Re: Interface with implied Constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-07-10 14:52 -0700
    Re: Interface with implied Constructor Roedy Green <see_website@mindprod.com.invalid> - 2013-07-10 16:02 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#24818

On Tue, 23 Jul 2013 14:43:48 -0700, Jim Gibson <jimsgibson@gmail.com>
wrote:

[snip]

>An interface only documents (requires or specifies, actually) /part/ of
>class behavior. There are usually other aspects of the class that must
>be addressed by its constructors. Those aspects are outside the scope
>of the interface.

     Of course.  I think that constructor signatures should be
possible to be one of them.

>Classes can implement more than one interface. What should the compiler
>demand in the case of multiple, mutually-exclusive constructor
>requirements?

     If they are really mutually exclusive, then that is an error.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#24820

On 07/24/2013 05:27 PM, Gene Wirchenko wrote:
> On Tue, 23 Jul 2013 14:43:48 -0700, Jim Gibson <jimsgibson@gmail.com>
> wrote:
>
> [snip]
>
>> An interface only documents (requires or specifies, actually) /part/ of
>> class behavior. There are usually other aspects of the class that must
>> be addressed by its constructors. Those aspects are outside the scope
>> of the interface.
>
>       Of course.  I think that constructor signatures should be
> possible to be one of them.
>
>> Classes can implement more than one interface. What should the compiler
>> demand in the case of multiple, mutually-exclusive constructor
>> requirements?
>
>       If they are really mutually exclusive, then that is an error.
>
> Sincerely,
>
> Gene Wirchenko
>
Let's say that constructors are allowed in interfaces. There'd be no 
problem in having multiple constructors in a single interface. The 
requirement would be, as for other methods, that you define all of them 
in an implementing class.

Any given interface would be satisfied if you constructed an object 
using one of those declared constructors.

But now mix in interface #2, with its own constructor signatures. You 
can't very well expect interface designers to be aware of all other 
interfaces, for starters, so if any interface is allowed constructor 
signatures, *all* of them ought to be.

And it seems reasonable to me that each interface can expect _one_ of 
its constructors to be used.

I don't see this being practical. Constructors are about what an object 
*is*, interfaces specify what an object *does*.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24839

On 24.07.2013 23:20, Arved Sandstrom wrote:

> Let's say that constructors are allowed in interfaces. There'd be no
> problem in having multiple constructors in a single interface. The
> requirement would be, as for other methods, that you define all of them
> in an implementing class.

Since constructors are unnamed (or put it differently: you have no 
choice) the likeliness of real conflicts seems higher to me than for 
ordinary methods in interfaces.  (A conflict I am talking about is for 
example when two methods with identical argument list but different and 
incompatible exceptions exist. Ordinary methods would also have to share 
the name but the constructor declaration would probably use a specific 
keyword.)

interface X {
   construct (int x, int y) throws FooBarException;
}

> I don't see this being practical.

+1

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#24821

On Wed, 24 Jul 2013 13:27:57 -0700, Gene Wirchenko wrote:

> On Tue, 23 Jul 2013 14:43:48 -0700, Jim Gibson <jimsgibson@gmail.com>
> wrote:
>>Classes can implement more than one interface. What should the compiler
>>demand in the case of multiple, mutually-exclusive constructor
>>requirements?
> 
>      If they are really mutually exclusive, then that is an error.
>
I suspect he meant "mutually disjoint", i.e. have no arguments in common,
which is a distinct possibility. To me that sounds like a good argument 
for excluding constructors from interface definitions.

In any case, you can always lock down the whole interface by declaring  
an abstract class that implements the methods in the interface(s) as 
abstract methods and declares concrete constructor(s). 

Works for me.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#24822

On 7/24/2013 5:18 PM, Martin Gregorie wrote:
> On Wed, 24 Jul 2013 13:27:57 -0700, Gene Wirchenko wrote:
>
>> On Tue, 23 Jul 2013 14:43:48 -0700, Jim Gibson <jimsgibson@gmail.com>
>> wrote:
>>> Classes can implement more than one interface. What should the compiler
>>> demand in the case of multiple, mutually-exclusive constructor
>>> requirements?
>>
>>       If they are really mutually exclusive, then that is an error.
>>
> I suspect he meant "mutually disjoint", i.e. have no arguments in common,
> which is a distinct possibility. To me that sounds like a good argument
> for excluding constructors from interface definitions.

     "Ayeh."  It would be even more confusing, I think, if two
interfaces specified constructors with identical signatures but
different intent:

	interface Flexible {
	    Flexible(double stiffness);  // constructor spec.
	    ... methods ...
	}

	interface Edible {
	    Edible(double caloriesPerGram);  // constructor
	    ... methods ...
	}

	class LicoriceStick implements Flexible, Edible {
	    // Constructor mandated by both interfaces:
	    LicoriceStick(double whatAttributeDoesThisGovern) {

> In any case, you can always lock down the whole interface by declaring
> an abstract class that implements the methods in the interface(s) as
> abstract methods and declares concrete constructor(s).

     That still doesn't mandate any particular form of constructor
for concrete subclasses.  It does, however, require that each
subclass constructor have enough information available to use in
an invocation of one of the abstract class' constructors, so a
certain amount of influence is present.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24811

On 7/23/2013 5:32 PM, Gene Wirchenko wrote:
> On Mon, 22 Jul 2013 16:02:05 -0400, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote:
>
>> On 7/22/2013 3:39 PM, Gene Wirchenko wrote:
>>> [...] I just want a  prototype of the
>>> constructor with the rest of the prototypes.
>>
>>      I don't think anyone's in doubt about what you and Richard
>> want.  The question that still burns is:
>>
>>                                "Why?"
>
>       An interface documents.  I can put additional comments in there
> and do because it helps the signatures make sense.  Since I have all
> this, why not have the constructors there, too?  Then, I have the API
> documented in one place.

     An interface documents -- and also specifies, mandates,
requires, and enforces.

>>      Perhaps if you'd offer a concrete example...?  To avoid charges
>
>       Read my pargraph above.
>
>> of made-up-ness, take an existing interface that you think would be
>> more useful if it could specify constructors, and exhibit the
>> constructors you'd like it to specify.  Please use an interface
>> that's not some creature of your own; if the idea is useful, there
>> surely must be some java or javax interfaces that could use it.
>> (If there aren't, that casts some doubt on the utility of the
>> construct ...)
>
>       It would document the class in one place.

     Are you proposing to do away with the class' own JavaDoc?
Also, what happens to "in one place" when a class implements
more than one interface?

>       I have already done this.  I added comments to my interfaces
> stating what the constructor signatures were.  I would like to have
> Java enforce constructor signatures.  Note that I am fine with this
> being optional so you need not worry about it.
>
>>      Then, maybe, we can get away from this childish "It's behavior!"
>> "No, it's implementation!" back-and-forth.  A use case, please.
>
>       For me, it is such a general situation that a use case is gilding
> the lily.  If you were to ask me for a use case for using a for
> statement, it would be about the same level.

     That level being "beneath contempt," I guess?

     In summary, we've still seen not even one use case.  We've
seen assertions by you and by Richard that the capability would
be of great utility, yet nobody's offered even one example of
a "well-known" interface that could benefit from it.  That, I
think, should raise a doubt or two.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24819

On Tue, 23 Jul 2013 18:19:20 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

>On 7/23/2013 5:32 PM, Gene Wirchenko wrote:
>> On Mon, 22 Jul 2013 16:02:05 -0400, Eric Sosman
>> <esosman@comcast-dot-net.invalid> wrote:
>>
>>> On 7/22/2013 3:39 PM, Gene Wirchenko wrote:
>>>> [...] I just want a  prototype of the
>>>> constructor with the rest of the prototypes.
>>>
>>>      I don't think anyone's in doubt about what you and Richard
>>> want.  The question that still burns is:
>>>
>>>                                "Why?"
>>
>>       An interface documents.  I can put additional comments in there
>> and do because it helps the signatures make sense.  Since I have all
>> this, why not have the constructors there, too?  Then, I have the API
>> documented in one place.
>
>     An interface documents -- and also specifies, mandates,
>requires, and enforces.
>
>>>      Perhaps if you'd offer a concrete example...?  To avoid charges
>>
>>       Read my pargraph above.
>>
>>> of made-up-ness, take an existing interface that you think would be
>>> more useful if it could specify constructors, and exhibit the
>>> constructors you'd like it to specify.  Please use an interface
>>> that's not some creature of your own; if the idea is useful, there
>>> surely must be some java or javax interfaces that could use it.
>>> (If there aren't, that casts some doubt on the utility of the
>>> construct ...)
>>
>>       It would document the class in one place.
>
>     Are you proposing to do away with the class' own JavaDoc?
>Also, what happens to "in one place" when a class implements
>more than one interface?

     No, but it would be nice for the API.

>>       I have already done this.  I added comments to my interfaces
>> stating what the constructor signatures were.  I would like to have
>> Java enforce constructor signatures.  Note that I am fine with this
>> being optional so you need not worry about it.
>>
>>>      Then, maybe, we can get away from this childish "It's behavior!"
>>> "No, it's implementation!" back-and-forth.  A use case, please.
>>
>>       For me, it is such a general situation that a use case is gilding
>> the lily.  If you were to ask me for a use case for using a for
>> statement, it would be about the same level.
>
>     That level being "beneath contempt," I guess?

     Well, you keep clamouring for a use case.  It has already been
given.  Maybe you disagree with doing it that way, but it is what some
of us want.

>     In summary, we've still seen not even one use case.  We've

     I have kept giving the example of documenting all of the API.

>seen assertions by you and by Richard that the capability would
>be of great utility, yet nobody's offered even one example of
>a "well-known" interface that could benefit from it.  That, I

     I do not care whether it would not be useful for a well-known
interface; I care whether it would be useful for me.  

>think, should raise a doubt or two.

     Well,  I have not claimed that everyone would want to use it.  I
found it odd when I first encountered Java interfaces that
constructors were not included in what could be specified.  I continue
to do so.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#24848

On 23/07/13 22:32, Gene Wirchenko wrote:
> I would like to have
> Java enforce constructor signatures.

In following this thread, I'm finding this desire for interface 
constructors totally bizarre.  I wouldn't be surprised if I once 
(briefly) wanted them, but now I immediately think 'factory interface', 
concoct something, and find it totally satisfactory.  If you want to be 
able to create a Foo from an argument list, define an interface type to 
express it:

   interface FooFactory {
     Foo createFoo(int x, int y);
   }

It totally decouples construction from the functionality of a Foo. The 
FooFactory implementation just acts as an adapter between the available 
arguments and the configuration required by a particular Foo 
implementation's constructors.  Not all of the configuration needs to 
come from the arguments; fill in missing parts with constants or get 
them from the environment.  Not all arguments need to be used.  The 
factory could choose different constructors depending on argument 
values, or return cached/pooled objects if that's compatible with the 
factory type's informal contract, or pass in some arguments via the 
constructor and others via reconfiguration methods.  Multiple FooFactory 
implementations could use the same Foo implementation.  Multiple factory 
types could be used when there are multiple contexts (with varying 
available arguments) that all, nevertheless, demand the creation of a Foo.

Coding to use a factory in the dynamic case (where a factory class's 
name is given as a string) is simple:

   Foo foo = Class.forName(clazzName)
                  .asSubclass(FooFactory.class)
                  .getConstructor()
                  .newInstance()
                  .createFoo(x, y);

This is type-safe and easy to refactor the argument list.

If you had a way to impose a constructor Foo(int x, int y) on all Foo 
implementations, what would you write instead?

   Foo foo = Class.forName(clazzName)
                  .asSubclass(Foo.class)
                  .getConstructor(new Class<?>[] { Integer.CLASS, Integer.CLASS })
                  .newInstance(new Object[] { x, y });

I think this is identical to what you'd write according to the OP's 
preferred option, where you assume that the named class has a compatible 
constructor.  It still lacks the type safety and refactorability of the 
factory code, and all you gain is the assurance that getConstructor 
won't fail.  But is that very valuable, when either approach could fail 
at run time simply by naming a class that doesn't implement 
Foo/FooFactory, or by naming a non-existent class?



-- 
ss at comp dot lancs dot ac dot uk

[toc] | [prev] | [next] | [standalone]

#24763

On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:

> On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
> <asandstrom2@eastlink.ca> wrote:
> 
> [snip]
> 
>>I'll be honest, Robert, personally I consider the behaviour of an object
>>- the kinds of things you could specify in an interface - to be what the
>>*initialized* object can (should) do.
> 
>      But there is more to it than that.  There is also getting it
> initialised.  That should also be part of the API.  I would not enforce
> that it has to, but I sure would like the option to specify constructor
> signatures in an interface.
>
Yes, agreed. I tend to extend superclasses instead of using an interface 
for exactly that reason.

 
>>I seriously dislike init() methods, not just in Java. Particularly if
>>there is no sensible un-init()'ed object for the class. I just don't see
>>any credible argument for them. Like Richard said, actually:
>>"half-baked".
>>
I take the opposite approach to Robert over that for one reason: that the 
only way to report init errors in a constructor is to throw an Exception, 
which means the instance declaration often needs to go inside a try/catch 
block which can screw up scoping. If init errors are possible and must be 
caught, I prefer to use a constructor that can't do anything that needs 
an Exception to be thrown and finish the job with an init() method that 
can go in the following try/catch block along with (some of) the other 
method calls.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#24764

On 07/19/2013 06:21 PM, Martin Gregorie wrote:
> On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:
>
>> On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
>> <asandstrom2@eastlink.ca> wrote:
>>
>> [snip]
>>
>>> I'll be honest, Robert, personally I consider the behaviour of an object
>>> - the kinds of things you could specify in an interface - to be what the
>>> *initialized* object can (should) do.
>>
>>       But there is more to it than that.  There is also getting it
>> initialised.  That should also be part of the API.  I would not enforce
>> that it has to, but I sure would like the option to specify constructor
>> signatures in an interface.
>>
> Yes, agreed. I tend to extend superclasses instead of using an interface
> for exactly that reason.
>
[ SNIP ]

Which is one reason you use abstract classes. If you want to supply 
constructors, implement them, and put them in an abstract class. It's 
the right place: in my continuing opinion ctors are an implementation 
detail.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24765

On 7/19/2013 5:56 PM, Arved Sandstrom wrote:
> [...]
> Which is one reason you use abstract classes. If you want to supply
> constructors, implement them, and put them in an abstract class. It's
> the right place: in my continuing opinion ctors are an implementation
> detail.

     Uhm, sorry, I don't get it.  Such a constructor would only
be callable from the constructor of a subclass, and there's still
nothing to require that the subclass provide any particular style
of constructor.

     (As mentioned elsethread I don't think interface-mandated
constructors would be useful.  I'm just wondering how you'd use
abstract classes to achieve the not-so-useful effect.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24766

On 07/19/2013 07:10 PM, Eric Sosman wrote:
> On 7/19/2013 5:56 PM, Arved Sandstrom wrote:
>> [...]
>> Which is one reason you use abstract classes. If you want to supply
>> constructors, implement them, and put them in an abstract class. It's
>> the right place: in my continuing opinion ctors are an implementation
>> detail.
>
>      Uhm, sorry, I don't get it.  Such a constructor would only
> be callable from the constructor of a subclass, and there's still
> nothing to require that the subclass provide any particular style
> of constructor.
>
>      (As mentioned elsethread I don't think interface-mandated
> constructors would be useful.  I'm just wondering how you'd use
> abstract classes to achieve the not-so-useful effect.)
>
Sure, it's imperfect. The best you can hope for is the the subclass uses 
one of the provided constructors. It works reasonably well with Exception.

But like I said I don't think much of any system that attempts to 
mandate how a class builds itself. I always figured that was up to the 
class itself.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24771

On 7/20/2013 7:46 AM, Arved Sandstrom wrote:
> On 07/19/2013 07:10 PM, Eric Sosman wrote:
>> On 7/19/2013 5:56 PM, Arved Sandstrom wrote:
>>> [...]
>>> Which is one reason you use abstract classes. If you want to supply
>>> constructors, implement them, and put them in an abstract class. It's
>>> the right place: in my continuing opinion ctors are an implementation
>>> detail.
>>
>>      Uhm, sorry, I don't get it.  Such a constructor would only
>> be callable from the constructor of a subclass, and there's still
>> nothing to require that the subclass provide any particular style
>> of constructor.
>>
>>      (As mentioned elsethread I don't think interface-mandated
>> constructors would be useful.  I'm just wondering how you'd use
>> abstract classes to achieve the not-so-useful effect.)
>>
> Sure, it's imperfect. The best you can hope for is the the subclass uses
> one of the provided constructors. It works reasonably well with Exception.
>
> But like I said I don't think much of any system that attempts to
> mandate how a class builds itself. I always figured that was up to the
> class itself.

I didn't say "mandated" and I'm not sure anyone else did besides yourself.

In the case of my Applet where I'm controlling the mainline (via and 
init() method ironically enough). The user-supplied class, for getting 
things like username/password etc and optionally displaying a console 
window, is going to be pretty specialized. However, if a generic(ish) 
class you have happens to provide an opportunity for code re-use then 
that's peachy. The closest I get to "mandatory" is to say "Regardless of 
any other constructors, I require you to provide either an empty 
constructor or one which takes a Tier3Ambience object as its only 
parameter".

If you're all so in love with init() methods then after setting 
non-standard-constructor-init-reqd = true in the constructor, your 
getSalutation() method can call all the functionality it wants even 
passing "this" for callbacks if it so desires.

For dynamically, run-time loaded, code I just like my method. If you'd 
prefer not to avail yourselves of all the lovely methods that 
Tier3Ambience makes visible to you then don't use it.
>
> AHS

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#24772

On 07/20/2013 01:42 AM, Richard Maher wrote:
> On 7/20/2013 7:46 AM, Arved Sandstrom wrote:
>> On 07/19/2013 07:10 PM, Eric Sosman wrote:
>>> On 7/19/2013 5:56 PM, Arved Sandstrom wrote:
>>>> [...]
>>>> Which is one reason you use abstract classes. If you want to supply
>>>> constructors, implement them, and put them in an abstract class. It's
>>>> the right place: in my continuing opinion ctors are an implementation
>>>> detail.
>>>
>>>      Uhm, sorry, I don't get it.  Such a constructor would only
>>> be callable from the constructor of a subclass, and there's still
>>> nothing to require that the subclass provide any particular style
>>> of constructor.
>>>
>>>      (As mentioned elsethread I don't think interface-mandated
>>> constructors would be useful.  I'm just wondering how you'd use
>>> abstract classes to achieve the not-so-useful effect.)
>>>
>> Sure, it's imperfect. The best you can hope for is the the subclass uses
>> one of the provided constructors. It works reasonably well with
>> Exception.
>>
>> But like I said I don't think much of any system that attempts to
>> mandate how a class builds itself. I always figured that was up to the
>> class itself.
>
> I didn't say "mandated" and I'm not sure anyone else did besides yourself.
[ SNIP ]

I wasn't necessarily replying directly to you. But an interface 
*mandates*, and so if you were somehow able to put constructors in an 
interface, they'd be mandated.

>
> If you're all so in love with init() methods then after setting
> non-standard-constructor-init-reqd = true in the constructor, your
> getSalutation() method can call all the functionality it wants even
> passing "this" for callbacks if it so desires.

The "you're all" doesn't include me. I haven't used any form of init() 
method for a long time.

> For dynamically, run-time loaded, code I just like my method. If you'd
> prefer not to avail yourselves of all the lovely methods that
> Tier3Ambience makes visible to you then don't use it.
>>
>> AHS
>
> Cheers Richard Maher
>

For what it's worth I have done more or less what you are doing, using 
reflection and locating a constructor with certain argument types, a 
number of times. Most recently, to convert results of JPA native queries 
into lists of non-entity objects.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24774

On 7/20/2013 12:42 AM, Richard Maher wrote:
> On 7/20/2013 7:46 AM, Arved Sandstrom wrote:
>>[...]
>> But like I said I don't think much of any system that attempts to
>> mandate how a class builds itself. I always figured that was up to the
>> class itself.
>
> I didn't say "mandated" and I'm not sure anyone else did besides yourself.
>
> In the case of my Applet where I'm controlling the mainline (via and
> init() method ironically enough). The user-supplied class, for getting
> things like username/password etc and optionally displaying a console
> window, is going to be pretty specialized. However, if a generic(ish)
> class you have happens to provide an opportunity for code re-use then
> that's peachy. The closest I get to "mandatory" is to say "Regardless of
> any other constructors, I require you to provide either an empty
> constructor or one which takes a Tier3Ambience object as its only
> parameter".

     So: Not "mandatory," but "required."  Subtle.

     Is this like the United States' "voluntary" income tax payments?
(You don't *have* to pay the tax, but if you don't the government
may garnish your wages, seize your property, and/or put you in jail.
The choice is entirely yours, to make as freely as you please.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24768

In article <kscaks$4qd$4@dont-email.me>,
 Martin Gregorie <martin@address-in-sig.invalid> wrote:

> On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:
> 
> > On Thu, 18 Jul 2013 23:21:35 -0300, Arved Sandstrom
> > <asandstrom2@eastlink.ca> wrote:
> > 
> > [snip]
> > 
> >>I'll be honest, Robert, personally I consider the behaviour of an object
> >>- the kinds of things you could specify in an interface - to be what the
> >>*initialized* object can (should) do.
> > 
> >      But there is more to it than that.  There is also getting it
> > initialised.  That should also be part of the API.  I would not enforce
> > that it has to, but I sure would like the option to specify constructor
> > signatures in an interface.
> >
> Yes, agreed. I tend to extend superclasses instead of using an interface 
> for exactly that reason.
> 
>  
> >>I seriously dislike init() methods, not just in Java. Particularly if
> >>there is no sensible un-init()'ed object for the class. I just don't see
> >>any credible argument for them. Like Richard said, actually:
> >>"half-baked".
> >>
> I take the opposite approach to Robert over that for one reason: that the 
> only way to report init errors in a constructor is to throw an Exception, 
> which means the instance declaration often needs to go inside a try/catch 
> block which can screw up scoping. If init errors are possible and must be 
> caught, I prefer to use a constructor that can't do anything that needs 
> an Exception to be thrown and finish the job with an init() method that 
> can go in the following try/catch block along with (some of) the other 
> method calls.

You never want public constructors that produce incomplete objects.  
They pollute your application and cause recurring failures long after 
the original fault.  It's too difficult to debug all the places where 
the object is constructed and possibly leaks out of scope without full 
initialization.  It's best if the minimum requirements for an object's 
functionality are assigned in the constructor and 'final'.

I only use initialization methods for private implementations where it's 
easy to control the scope of an uninitialized object.  A typical case is 
where a new cached object takes a very long time to initialize.  
Simplified example:

   
private final HashMap<String, CachableThing> cache=
   new HashMap<String, CachableThing>();

private static class CachableThing implements Thing
{ ... }

public Thing getThing(String key) throws SomeException
{
   CachableThing t;
   synchronized (cache)
   {
      t= cache.get(key);
      if (t == null)
         cache.put(key, t= new CachableThing());
   }
   
   synchronized (t)
   {
      if (!t.initialized())
          t.init(key);   //Very slow and may intermittently throw
   }
   
   return t;
}
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#24769

On 7/19/2013 7:20 PM, Kevin McMurtrie wrote:
> You never want public constructors that produce incomplete objects.
> They pollute your application and cause recurring failures long after
> the original fault.  It's too difficult to debug all the places where


While I think you have some good points here, I also think it's OK to 
design an object or interface with a defined life-cycle.

For example a plain Socket must connected before it can be meaningfully 
used.

   Socket sock = new Socket();
   sock.connect( ... );

(Likewise the socket must be closed also.)

While not exactly the same as a generic init() method, it's along the 
same idea, and I don't see Java programs in general "polluted" with 
partially constructed sockets.

Files and Paths take a slightly different approach;  they use static 
methods in the Files class to get a stream (or File uses the 
FileI/OStream classes).  I'm not sure I like this however.  Why wouldn't 
a basic open() method on the File object just be easier?

So there's three different ways: lifecycle (i.e., open/close), static 
method (Files) and ctor for another helper class (like FileI/OStream). 
The lifecycle option seems the most straight forward to me.

[toc] | [prev] | [next] | [standalone]

#24770

On 7/20/2013 11:11 AM, markspace wrote:
> While not exactly the same as a generic init() method, it's along the
> same idea, and I don't see Java programs in general "polluted" with
> partially constructed sockets.

Sockets are stateful without connections.
>
> Files and Paths take a slightly different approach;  they use static
> methods in the Files class to get a stream (or File uses the
> FileI/OStream classes).  I'm not sure I like this however.  Why wouldn't
> a basic open() method on the File object just be easier?
>
> So there's three different ways: lifecycle (i.e., open/close), static
> method (Files) and ctor for another helper class (like FileI/OStream).
> The lifecycle option seems the most straight forward to me.
>
>

On the subject of close() and reason now why any such classes should not 
implement java.lang.AutoCloseable? Idempotency not withstanding.

Anyway for the sake of narrowing this thread her is the interface I'm 
asking the user to implement: -

/**
  * Copyright Tier3 (c) Software. All rights reserved.
  *
  * Contract for user class that will specify and process
  * the server handshake.
  *
  * @author    Richard Maher
  * @version   1.0
  *
  */

package tier3Client;

import java.awt.Color;
import java.lang.AutoCloseable;

interface Tier3Handshake extends AutoCloseable{

     String   getSalutation();

     boolean  setResponse(String remoteResp);

     void     setRcvd(int bytes);

     void     setSent(int bytes);

     void     setRefCnt(int pages);

     void     appendMsg(String msg, Color color);

     void     appendMsg(String msg);
	
}

[toc] | [prev] | [next] | [standalone]

#24773

On 07/20/2013 12:11 AM, markspace wrote:
> On 7/19/2013 7:20 PM, Kevin McMurtrie wrote:
>> You never want public constructors that produce incomplete objects.
>> They pollute your application and cause recurring failures long after
>> the original fault.  It's too difficult to debug all the places where
>
>
> While I think you have some good points here, I also think it's OK to
> design an object or interface with a defined life-cycle.
>
> For example a plain Socket must connected before it can be meaningfully
> used.
>
>    Socket sock = new Socket();
>    sock.connect( ... );
>
> (Likewise the socket must be closed also.)
>
> While not exactly the same as a generic init() method, it's along the
> same idea, and I don't see Java programs in general "polluted" with
> partially constructed sockets.
[ SNIP ]

You do see Java programs littered with pairs of the 2 statements you 
just described. With the appropriate Socket ctor you'd have one statement.

It's a matter of debate as to whether a "new Socket()" is partially 
constructed or not. I'd say that it is, it doesn't know how to do 
anything much useful at that point. If your motivation is to set certain 
connection options, before connecting, java.net.Socket has better 
approaches.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24776

On 19.07.2013 23:21, Martin Gregorie wrote:
> On Fri, 19 Jul 2013 12:38:19 -0700, Gene Wirchenko wrote:

>>> I seriously dislike init() methods, not just in Java. Particularly if

Just for the record: I am also not very fond of init methods.  But I 
don't condemn them either.  It's not too unusual to require specific 
order of method invocations in an interface.  For example you need to 
have invoked java.util.List.add() once before List.get(0) can return 
anything meaningful.

>>> there is no sensible un-init()'ed object for the class. I just don't see
>>> any credible argument for them. Like Richard said, actually:
>>> "half-baked".
>>>
> I take the opposite approach to Robert over that for one reason: that the
> only way to report init errors in a constructor is to throw an Exception,
> which means the instance declaration often needs to go inside a try/catch
> block which can screw up scoping.

In what ways does this screw up scoping?

> If init errors are possible and must be
> caught, I prefer to use a constructor that can't do anything that needs
> an Exception to be thrown and finish the job with an init() method that
> can go in the following try/catch block along with (some of) the other
> method calls.

 From your description I am not sure I understood the pattern you are 
advertising here.  Can you show this in code?  The thing which irritates 
me is that you want to have a "following try/catch" block.  What for?

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web