Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java Feature Proposal

Reply
Thread Tools

Java Feature Proposal

 
 
christopher diggins
Guest
Posts: n/a
 
      02-04-2004
A feature that I find missing in Java is the ability to write
functions in interfaces that can call other functions of the interface.
Given an interface ISomeInteface the only way we can write a general purpose
function to operate on all objects which implement that interface is through
the following style of declaration (in the following code snippets i is an
interface variable of type ISomeInterface) :

SomeStaticClass {
FuBar(ISomeInterface i) { ... }
}

Which when invoked requires the following syntax :

SomeStaticClass.FuBar(i);


What would be more appropriate would be to be able to define interface
functions which allow the more straightforward object-like syntax of :

i.FuBar()

For lack of a better term I refer to these kinds of functions as interface
extensions, in order to distinguish them from interface contract (the set of
functions to be implemented, by an implementor of the interface). One
possible approach for adding this feature is to prefix extension functions
with a keyword modifier, such as in the following notation :

SomeInterface {
extension FuBar() { ... }
}

Another possibility, and my preferred option, is to divide the interface
into two sections :

SomeInterface {
contract
...
extension
FuBar();
}

Would anyone else like this feature?

--
Christopher Diggins
yet another language designer
http://www.heron-language.com


 
Reply With Quote
 
 
 
 
Anton Spaans
Guest
Posts: n/a
 
      02-04-2004

"christopher diggins" <(E-Mail Removed)> wrote in message
news:wVdUb.98591$(E-Mail Removed).. .
> A feature that I find missing in Java is the ability to write
> functions in interfaces that can call other functions of the interface.
> Given an interface ISomeInteface the only way we can write a general

purpose
> function to operate on all objects which implement that interface is

through
> the following style of declaration (in the following code snippets i is an
> interface variable of type ISomeInterface) :
>
> SomeStaticClass {
> FuBar(ISomeInterface i) { ... }
> }
>
> Which when invoked requires the following syntax :
>
> SomeStaticClass.FuBar(i);
>
>
> What would be more appropriate would be to be able to define interface
> functions which allow the more straightforward object-like syntax of :
>
> i.FuBar()
>
> For lack of a better term I refer to these kinds of functions as interface
> extensions, in order to distinguish them from interface contract (the set

of
> functions to be implemented, by an implementor of the interface). One
> possible approach for adding this feature is to prefix extension functions
> with a keyword modifier, such as in the following notation :
>
> SomeInterface {
> extension FuBar() { ... }
> }
>
> Another possibility, and my preferred option, is to divide the interface
> into two sections :
>
> SomeInterface {
> contract
> ...
> extension
> FuBar();
> }
>
> Would anyone else like this feature?
>
> --
> Christopher Diggins
> yet another language designer
> http://www.heron-language.com
>
>


I don't understand why you need this feature. This construct will do it in a
similar way:

public interface ISomeInterface
{
public void FuBar();
}

public abstract class ASomeInterface implements ISomeInterface
{
public final void FuBar()
{
... some code ...
}
}

public class SomeInterfaceImplementer extends ASomeInterface
{
...
}

Then you can do this:
ISomeInterface i = new SomeInterfaceImplementer()
i.FuBar();

-- Anton Spaans.


 
Reply With Quote
 
 
 
 
lcan
Guest
Posts: n/a
 
      02-04-2004
Can this be done via abstract class instead of interface, which inetends to
be a pure abstract class?

Regards,
--lc
"christopher diggins" <(E-Mail Removed)> wrote in message
news:wVdUb.98591$(E-Mail Removed).. .
> A feature that I find missing in Java is the ability to write
> functions in interfaces that can call other functions of the interface.
> Given an interface ISomeInteface the only way we can write a general

purpose
> function to operate on all objects which implement that interface is

through
> the following style of declaration (in the following code snippets i is an
> interface variable of type ISomeInterface) :
>
> SomeStaticClass {
> FuBar(ISomeInterface i) { ... }
> }
>
> Which when invoked requires the following syntax :
>
> SomeStaticClass.FuBar(i);
>
>
> What would be more appropriate would be to be able to define interface
> functions which allow the more straightforward object-like syntax of :
>
> i.FuBar()
>
> For lack of a better term I refer to these kinds of functions as interface
> extensions, in order to distinguish them from interface contract (the set

of
> functions to be implemented, by an implementor of the interface). One
> possible approach for adding this feature is to prefix extension functions
> with a keyword modifier, such as in the following notation :
>
> SomeInterface {
> extension FuBar() { ... }
> }
>
> Another possibility, and my preferred option, is to divide the interface
> into two sections :
>
> SomeInterface {
> contract
> ...
> extension
> FuBar();
> }
>
> Would anyone else like this feature?
>
> --
> Christopher Diggins
> yet another language designer
> http://www.heron-language.com
>
>



 
Reply With Quote
 
Anton Spaans
Guest
Posts: n/a
 
      02-04-2004

"Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in
message news:(E-Mail Removed)...
>
> "christopher diggins" <(E-Mail Removed)> wrote in message
> news:wVdUb.98591$(E-Mail Removed).. .
> > A feature that I find missing in Java is the ability to write
> > functions in interfaces that can call other functions of the interface.
> > Given an interface ISomeInteface the only way we can write a general

> purpose
> > function to operate on all objects which implement that interface is

> through
> > the following style of declaration (in the following code snippets i is

an
> > interface variable of type ISomeInterface) :
> >
> > SomeStaticClass {
> > FuBar(ISomeInterface i) { ... }
> > }
> >
> > Which when invoked requires the following syntax :
> >
> > SomeStaticClass.FuBar(i);
> >
> >
> > What would be more appropriate would be to be able to define interface
> > functions which allow the more straightforward object-like syntax of :
> >
> > i.FuBar()
> >
> > For lack of a better term I refer to these kinds of functions as

interface
> > extensions, in order to distinguish them from interface contract (the

set
> of
> > functions to be implemented, by an implementor of the interface). One
> > possible approach for adding this feature is to prefix extension

functions
> > with a keyword modifier, such as in the following notation :
> >
> > SomeInterface {
> > extension FuBar() { ... }
> > }
> >
> > Another possibility, and my preferred option, is to divide the interface
> > into two sections :
> >
> > SomeInterface {
> > contract
> > ...
> > extension
> > FuBar();
> > }
> >
> > Would anyone else like this feature?
> >
> > --
> > Christopher Diggins
> > yet another language designer
> > http://www.heron-language.com
> >
> >

>
> I don't understand why you need this feature. This construct will do it in

a
> similar way:
>
> public interface ISomeInterface
> {
> public void FuBar();
> }
>
> public abstract class ASomeInterface implements ISomeInterface
> {
> public final void FuBar()
> {
> ... some code ...
> }
> }
>
> public class SomeInterfaceImplementer extends ASomeInterface
> {
> ...
> }
>
> Then you can do this:
> ISomeInterface i = new SomeInterfaceImplementer()
> i.FuBar();
>
> -- Anton Spaans.
>
>


Or skip the ISomeInterface all together... Just use the abstract
ASomeInterface:
ASomeInterface i = new SomeInterfaceImplementer();
i.FuBar();


 
Reply With Quote
 
christopher diggins
Guest
Posts: n/a
 
      02-04-2004


"Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in
message news:(E-Mail Removed)...
>
> "Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in
> message news:(E-Mail Removed)...
> >
> > "christopher diggins" <(E-Mail Removed)> wrote in message
> > news:wVdUb.98591$(E-Mail Removed).. .
> > > A feature that I find missing in Java is the ability to write
> > > functions in interfaces that can call other functions of the

interface.
> > > Given an interface ISomeInteface the only way we can write a general

> > purpose
> > > function to operate on all objects which implement that interface is

> > through
> > > the following style of declaration (in the following code snippets i

is
> an
> > > interface variable of type ISomeInterface) :
> > >
> > > SomeStaticClass {
> > > FuBar(ISomeInterface i) { ... }
> > > }
> > >
> > > Which when invoked requires the following syntax :
> > >
> > > SomeStaticClass.FuBar(i);
> > >
> > >
> > > What would be more appropriate would be to be able to define interface
> > > functions which allow the more straightforward object-like syntax of :
> > >
> > > i.FuBar()
> > >
> > > For lack of a better term I refer to these kinds of functions as

> interface
> > > extensions, in order to distinguish them from interface contract (the

> set
> > of
> > > functions to be implemented, by an implementor of the interface). One
> > > possible approach for adding this feature is to prefix extension

> functions
> > > with a keyword modifier, such as in the following notation :
> > >
> > > SomeInterface {
> > > extension FuBar() { ... }
> > > }
> > >
> > > Another possibility, and my preferred option, is to divide the

interface
> > > into two sections :
> > >
> > > SomeInterface {
> > > contract
> > > ...
> > > extension
> > > FuBar();
> > > }
> > >
> > > Would anyone else like this feature?
> > >
> > > --
> > > Christopher Diggins
> > > yet another language designer
> > > http://www.heron-language.com
> > >
> > >

> >
> > I don't understand why you need this feature. This construct will do it

in
> a
> > similar way:
> >
> > public interface ISomeInterface
> > {
> > public void FuBar();
> > }
> >
> > public abstract class ASomeInterface implements ISomeInterface
> > {
> > public final void FuBar()
> > {
> > ... some code ...
> > }
> > }
> >
> > public class SomeInterfaceImplementer extends ASomeInterface
> > {
> > ...
> > }
> >
> > Then you can do this:
> > ISomeInterface i = new SomeInterfaceImplementer()
> > i.FuBar();
> >
> > -- Anton Spaans.
> >
> >

>
> Or skip the ISomeInterface all together... Just use the abstract
> ASomeInterface:
> ASomeInterface i = new SomeInterfaceImplementer();
> i.FuBar();


Your examples though do not generalize to multiple interfaces.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com


 
Reply With Quote
 
Anton Spaans
Guest
Posts: n/a
 
      02-04-2004

"christopher diggins" <(E-Mail Removed)> wrote in message
newsieUb.99482$(E-Mail Removed).. .
>
>
> "Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in
> message news:(E-Mail Removed)...
> >
> > "Anton Spaans" <aspaans at(noSPAM) smarttime dot(noSPAM) com> wrote in
> > message news:(E-Mail Removed)...
> > >
> > > "christopher diggins" <(E-Mail Removed)> wrote in

message
> > > news:wVdUb.98591$(E-Mail Removed).. .
> > > > A feature that I find missing in Java is the ability to write
> > > > functions in interfaces that can call other functions of the

> interface.
> > > > Given an interface ISomeInteface the only way we can write a general
> > > purpose
> > > > function to operate on all objects which implement that interface is
> > > through
> > > > the following style of declaration (in the following code snippets i

> is
> > an
> > > > interface variable of type ISomeInterface) :
> > > >
> > > > SomeStaticClass {
> > > > FuBar(ISomeInterface i) { ... }
> > > > }
> > > >
> > > > Which when invoked requires the following syntax :
> > > >
> > > > SomeStaticClass.FuBar(i);
> > > >
> > > >
> > > > What would be more appropriate would be to be able to define

interface
> > > > functions which allow the more straightforward object-like syntax of

:
> > > >
> > > > i.FuBar()
> > > >
> > > > For lack of a better term I refer to these kinds of functions as

> > interface
> > > > extensions, in order to distinguish them from interface contract

(the
> > set
> > > of
> > > > functions to be implemented, by an implementor of the interface).

One
> > > > possible approach for adding this feature is to prefix extension

> > functions
> > > > with a keyword modifier, such as in the following notation :
> > > >
> > > > SomeInterface {
> > > > extension FuBar() { ... }
> > > > }
> > > >
> > > > Another possibility, and my preferred option, is to divide the

> interface
> > > > into two sections :
> > > >
> > > > SomeInterface {
> > > > contract
> > > > ...
> > > > extension
> > > > FuBar();
> > > > }
> > > >
> > > > Would anyone else like this feature?
> > > >
> > > > --
> > > > Christopher Diggins
> > > > yet another language designer
> > > > http://www.heron-language.com
> > > >
> > > >
> > >
> > > I don't understand why you need this feature. This construct will do

it
> in
> > a
> > > similar way:
> > >
> > > public interface ISomeInterface
> > > {
> > > public void FuBar();
> > > }
> > >
> > > public abstract class ASomeInterface implements ISomeInterface
> > > {
> > > public final void FuBar()
> > > {
> > > ... some code ...
> > > }
> > > }
> > >
> > > public class SomeInterfaceImplementer extends ASomeInterface
> > > {
> > > ...
> > > }
> > >
> > > Then you can do this:
> > > ISomeInterface i = new SomeInterfaceImplementer()
> > > i.FuBar();
> > >
> > > -- Anton Spaans.
> > >
> > >

> >
> > Or skip the ISomeInterface all together... Just use the abstract
> > ASomeInterface:
> > ASomeInterface i = new SomeInterfaceImplementer();
> > i.FuBar();

>
> Your examples though do not generalize to multiple interfaces.
>
> --
> Christopher Diggins
> yet another language designer
> http://www.heron-language.com
>
>


I agree, but you can not inherit multiple implementations (multiple
'extends' clauses) in Java, only multiple interfaces ('implements' clauses).
With your new proposed construct, you basically would violate that rule
(e.g. a class implementing two interfaces that each 'extend' - using your
new feature - FuBar(). Which of the two FuBar implementations will then be
used?).

It would then be 'simpler' to allow multiple implementation inheritance
again...
-- Anton Spaans.




 
Reply With Quote
 
christopher diggins
Guest
Posts: n/a
 
      02-05-2004

"lcan" <(E-Mail Removed)> wrote in message
news:%aeUb.6818$An3.1477@edtnps84...
> Can this be done via abstract class instead of interface, which inetends

to
> be a pure abstract class?
>
> Regards,
> --lc


Yes it can, but as I mention in response to Anton Spaans in the other
thread, this doesn't work with regards to multiple implementation.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com


 
Reply With Quote
 
christopher diggins
Guest
Posts: n/a
 
      02-05-2004
> > > Or skip the ISomeInterface all together... Just use the abstract
> > > ASomeInterface:
> > > ASomeInterface i = new SomeInterfaceImplementer();
> > > i.FuBar();

> >
> > Your examples though do not generalize to multiple interfaces.
> >

>
> I agree, but you can not inherit multiple implementations (multiple
> 'extends' clauses) in Java, only multiple interfaces ('implements'

clauses).
> With your new proposed construct, you basically would violate that rule
> (e.g. a class implementing two interfaces that each 'extend' - using your
> new feature - FuBar(). Which of the two FuBar implementations will then be
> used?).
>
> It would then be 'simpler' to allow multiple implementation inheritance
> again...
> -- Anton Spaans.


I do not agree that it would be simpler to allow multiple inheritance.

Let's go to the beginning : implementing an interface is not the same thing
as inheritance therefore you do not "inherit" an extension. An extension is
a function which operates on an interface by calling those functions as
implemented by the class. Any naming conflict is the same as any naming
conflict with interfaces themselves, simply cast to the correct interface to
make it explicit to the compiler which extension you are calling. There are
no "rules" being violated.

--
Christopher Diggins
yet another language designer
http://www.heron-language.com


 
Reply With Quote
 
BarryNL
Guest
Posts: n/a
 
      02-05-2004
christopher diggins wrote:
> A feature that I find missing in Java is the ability to write
> functions in interfaces that can call other functions of the interface.
> Given an interface ISomeInteface the only way we can write a general purpose
> function to operate on all objects which implement that interface is through
> the following style of declaration (in the following code snippets i is an
> interface variable of type ISomeInterface) :
>
> SomeStaticClass {
> FuBar(ISomeInterface i) { ... }
> }
>
> Which when invoked requires the following syntax :
>
> SomeStaticClass.FuBar(i);
>
>
> What would be more appropriate would be to be able to define interface
> functions which allow the more straightforward object-like syntax of :
>
> i.FuBar()
>
> For lack of a better term I refer to these kinds of functions as interface
> extensions, in order to distinguish them from interface contract (the set of
> functions to be implemented, by an implementor of the interface). One
> possible approach for adding this feature is to prefix extension functions
> with a keyword modifier, such as in the following notation :
>
> SomeInterface {
> extension FuBar() { ... }
> }
>
> Another possibility, and my preferred option, is to divide the interface
> into two sections :
>
> SomeInterface {
> contract
> ...
> extension
> FuBar();
> }
>
> Would anyone else like this feature?


Nope. I think it would be quite confusing. Do you have a concrete
example in mind? Everything I can think of where this might be useful is
better served by using an Adapter or Proxy pattern.
 
Reply With Quote
 
Anton Spaans
Guest
Posts: n/a
 
      02-05-2004

"christopher diggins" <(E-Mail Removed)> wrote in message
news:6RhUb.103894$(E-Mail Removed). ..
> > > > Or skip the ISomeInterface all together... Just use the abstract
> > > > ASomeInterface:
> > > > ASomeInterface i = new SomeInterfaceImplementer();
> > > > i.FuBar();
> > >
> > > Your examples though do not generalize to multiple interfaces.
> > >

> >
> > I agree, but you can not inherit multiple implementations (multiple
> > 'extends' clauses) in Java, only multiple interfaces ('implements'

> clauses).
> > With your new proposed construct, you basically would violate that rule
> > (e.g. a class implementing two interfaces that each 'extend' - using

your
> > new feature - FuBar(). Which of the two FuBar implementations will then

be
> > used?).
> >
> > It would then be 'simpler' to allow multiple implementation inheritance
> > again...
> > -- Anton Spaans.

>
> I do not agree that it would be simpler to allow multiple inheritance.
>
> Let's go to the beginning : implementing an interface is not the same

thing
> as inheritance therefore you do not "inherit" an extension. An extension

is
> a function which operates on an interface by calling those functions as
> implemented by the class. Any naming conflict is the same as any naming
> conflict with interfaces themselves, simply cast to the correct interface

to
> make it explicit to the compiler which extension you are calling. There

are
> no "rules" being violated.
>
> --
> Christopher Diggins
> yet another language designer
> http://www.heron-language.com
>
>


What then about this:
public interface IF1
{

extension
public void FuBar()
{ some impl }
}

public interface IF2
{

extension
public void FuBar()
{ some impl }
}

public class MyClass implements IF1, IF2
{
}

And code using the MyClass class:
MyClass mc = new MyClass();
// which FuBar implementation is called?
// Note that IF1 and IF2 may not always be public, so casting is not
always possible.
mc.FuBar();

-- Anton Spaans


 
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
Feature Proposal: Explicitly declare a struct (or class) as POD jmucchiello C++ 9 08-26-2009 07:43 PM
feature proposal, debug on exception Paul Rubin Python 3 05-21-2008 06:05 AM
py3k feature proposal: field auto-assignment in constructors coldpizza Python 45 01-29-2008 11:55 AM
Re: Feature Proposal: Sequence .join method Jp Calderone Python 2 10-08-2005 12:17 PM
Feature Proposal: Sequence .join method David Murmann Python 10 09-30-2005 11:19 PM



Advertisments