Home » Eclipse Projects » Technology Project and PMC » Why that "I*" (IResource, IJavaElement, ...)?
| Why that "I*" (IResource, IJavaElement, ...)? [message #49980] |
Mon, 24 March 2003 18:10  |
Eclipse User |
|
|
|
Originally posted by: sebastian.menge.uni-dortmund.de
Hi!
I'm trying to understand some parts of the Eclipse-API, and have one small
question. Many classes a plugin developer works with, are no classes but
interfaces. As far as I understand: The real implementation is hidden to
force developers to program against interfaces.
That's nice so far, but why then tag each with that "I"? And why that
comment in javadoc "This interface is not intended to be implemented by
clients." I think it's a bit confusing.
Perhaps someone can clear up my confusion.
regards, Sebastian.
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #50048 is a reply to message #49980] |
Mon, 24 March 2003 21:35  |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
Sebastian Menge wrote:
>Many classes a plugin developer works with, are no classes but
>interfaces. As far as I understand: The real implementation is hidden to
>force developers to program against interfaces.
>That's nice so far, but why then tag each with that "I"?
>
This a naming convention used in the Eclipse project.
> And why that
>comment in javadoc "This interface is not intended to be implemented by
>clients." I think it's a bit confusing.
>
Because some interface may or even have to be implemented by clients
while others are not intended to be implemented. What is confusing you?
Dani
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #50108 is a reply to message #50048] |
Mon, 24 March 2003 22:27 |
| Eclipse User |
|
|
|
Originally posted by: sebastian.menge.uni-dortmund.de
> Because some interface may or even have to be implemented by clients
> while others are not intended to be implemented. What is confusing you?
Where are the implementing classes?
Where is the need for this convention?
People can read Javadoc-API, so they dont need that convention to recognize
"it's an interface", or do I miss something?
thanks, Sebastian.
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #50166 is a reply to message #50108] |
Tue, 25 March 2003 11:09 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
Sebastian Menge wrote:
>>Because some interface may or even have to be implemented by clients
>>while others are not intended to be implemented. What is confusing you?
>>
>>
>
>Where are the implementing classes?
>
Browser for implementors in the code.
>Where is the need for this convention?
>
>People can read Javadoc-API, so they dont need that convention to recognize
>"it's an interface", or do I miss something?
>
Some people actually prefer to read code rather than Javadoc ;-) If you
see code like "if (a instance of C)" you do not know if C is an
interface or class unless you look at the Javadoc.
Dani
|
|
|
| OT: "I" is for Interface [message #50424 is a reply to message #50166] |
Tue, 25 March 2003 18:15 |
| Eclipse User |
|
|
|
Originally posted by: mccull1NOSPAMPLEASE.us.ibm.com
Off topic but..
I used to think the use of "I" in front of interfaces was a bad idea. I've
since changed my mind. Curious if anyone else has given much thought to
this...
Once upon a time on a project, I saw some interfaces with "I" in front of
them. This was on a project which apparently took it's lead from JLOG,
which does the same thing. I thought it was kind of goofy. "Why prefix it
with 'I'?" I wondered. I decided I didn't like it. My argument was: If
you do your job right, no one should even know that an interface is an
interface. If you define, code to, and use an interface such that it is
indistinguishable from a class, you have succeeded. Why would you want to
draw attention to something that should be transparent? The corollary
being: If the interface represents a Person, why not just call it "Person"?
It makes it clear to the user what it represents, it reads nicely, etc. In
theory, no one ever needs to see "PersonImpl". But, then I started playing
around with Eclipse, and I changed my tune.
In a project the size and scope of Eclipse -- and one with a huge number of
outside observers/users of the code -- having the "I" prefix makes the code
base easier to follow. It makes it clear what you should be using, and
helps you to distinguish the important stuff from the huge number of
behind-the-scenes classes. No confusion between implementors and
interfaces, or between the outward-facing API and the internal details. No
polluting the code with "Impl" postfixes. You always code to the interface,
you always know when you are using an interface, and the line between
"internal" and "API" is more clearly demarcated. So, now I am a fan of the
"I".
Just in case anyone cares :)
-Andrew
"Daniel Megert" <daniel.megert@gmx.net> wrote in message
news:b5pd9t$b3c$1@rogue.oti.com...
> Sebastian Menge wrote:
>
> >>Because some interface may or even have to be implemented by clients
> >>while others are not intended to be implemented. What is confusing you?
> >>
> >>
> >
> >Where are the implementing classes?
> >
> Browser for implementors in the code.
>
> >Where is the need for this convention?
> >
> >People can read Javadoc-API, so they dont need that convention to
recognize
> >"it's an interface", or do I miss something?
> >
> Some people actually prefer to read code rather than Javadoc ;-) If you
> see code like "if (a instance of C)" you do not know if C is an
> interface or class unless you look at the Javadoc.
>
> Dani
>
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #53011 is a reply to message #50166] |
Wed, 23 April 2003 11:43 |
| Eclipse User |
|
|
|
Originally posted by: simon+eclipse.tardell.se
Depending on naming conventions (naming conventions that are not standard,
at least) can be problematic, especially if you use code from outside
sources that are likely to have different deviations from standard naming
conventions. I do think that the need is correctly identified, but it would
have been nice if it could have been support by e.g. colour coding in the
editor (different colours available for interfaces, abstract and concrete
classes). There's an RFE coming your way...
Simon
"Daniel Megert" <daniel.megert@gmx.net> wrote in message
news:b5pd9t$b3c$1@rogue.oti.com...
> Sebastian Menge wrote:
>
> >>Because some interface may or even have to be implemented by clients
> >>while others are not intended to be implemented. What is confusing you?
> >>
> >>
> >
> >Where are the implementing classes?
> >
> Browser for implementors in the code.
>
> >Where is the need for this convention?
> >
> >People can read Javadoc-API, so they dont need that convention to
recognize
> >"it's an interface", or do I miss something?
> >
> Some people actually prefer to read code rather than Javadoc ;-) If you
> see code like "if (a instance of C)" you do not know if C is an
> interface or class unless you look at the Javadoc.
>
> Dani
>
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #59744 is a reply to message #50108] |
Tue, 11 November 2003 09:16 |
| Eclipse User |
|
|
|
Originally posted by: sineyourpitty2000.yahoo.com
Sebastian Menge wrote:
> > Because some interface may or even have to be implemented by clients
> > while others are not intended to be implemented. What is confusing you?
> Where are the implementing classes?
> Where is the need for this convention?
> People can read Javadoc-API, so they dont need that convention to recognize
> "it's an interface", or do I miss something?
> thanks, Sebastian.
Prefixing type qualifiers before a type name (in OO) or variable name is a
convention that sadly endures thanks to the "Hungarian" notation of
variable names and its prevalence in C and C++ code. (see Hungarian
notation, its worth a good laugh)
Remember that only recently did the convention of "short methods" -
(hopefully no more than 12 to 20 lines long) and proper encapsulation even
come into wide practice. In a *short* method, contained in an
appropriately encapsulated class - type qualifiers (on the variable name
or the declared type declaration) are unnecessary because you should be
dealing with objects in a short scope with an obvious meaning and a
transparent algorythm or pattern.
In the case of a "true" convention the "I*" is redundant because if the
coding standard is to *always* code to interfaces then you dont need to
put "I*" before anything. You are *ALWAYS* coding to an interface. So
assume an interface. The time it takes you to check what the factory
actually returns might be worth it -- or not.
Let's also remember that no sane OO programmer is using vi. And that our
wonderful state of the art object browsing development environments will
describe any type declaration with a mere tool tip mouse hover.
Or (optionally) - make friends with C++ cause thats where this really
comes from in my opinion.
I believe it is miopic in nature and is equivalent to the rampant
abbreviation tactics used which obscure the nature of things in software.
It's a time saver which really isnt a time saver because it creates
inconsistencies.
Why does a brain have to identify I before an interface when it doesnt
need to follow the same pattern C for classes and AC for abstract classes.
Carried forward the convention gets ridiculous.
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #591941 is a reply to message #49980] |
Mon, 24 March 2003 21:35 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
Sebastian Menge wrote:
>Many classes a plugin developer works with, are no classes but
>interfaces. As far as I understand: The real implementation is hidden to
>force developers to program against interfaces.
>That's nice so far, but why then tag each with that "I"?
>
This a naming convention used in the Eclipse project.
> And why that
>comment in javadoc "This interface is not intended to be implemented by
>clients." I think it's a bit confusing.
>
Because some interface may or even have to be implemented by clients
while others are not intended to be implemented. What is confusing you?
Dani
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #591964 is a reply to message #50048] |
Mon, 24 March 2003 22:27 |
| Eclipse User |
|
|
|
Originally posted by: sebastian.menge.uni-dortmund.de
> Because some interface may or even have to be implemented by clients
> while others are not intended to be implemented. What is confusing you?
Where are the implementing classes?
Where is the need for this convention?
People can read Javadoc-API, so they dont need that convention to recognize
"it's an interface", or do I miss something?
thanks, Sebastian.
|
|
|
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #591986 is a reply to message #50108] |
Tue, 25 March 2003 11:09 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
Sebastian Menge wrote:
>>Because some interface may or even have to be implemented by clients
>>while others are not intended to be implemented. What is confusing you?
>>
>>
>
>Where are the implementing classes?
>
Browser for implementors in the code.
>Where is the need for this convention?
>
>People can read Javadoc-API, so they dont need that convention to recognize
>"it's an interface", or do I miss something?
>
Some people actually prefer to read code rather than Javadoc ;-) If you
see code like "if (a instance of C)" you do not know if C is an
interface or class unless you look at the Javadoc.
Dani
|
|
|
| OT: "I" is for Interface [message #592098 is a reply to message #50166] |
Tue, 25 March 2003 18:15 |
 Andrew McCullough
Messages: 26
Registered: July 2009 |
Junior Member |
|
|
Off topic but..
I used to think the use of "I" in front of interfaces was a bad idea. I've
since changed my mind. Curious if anyone else has given much thought to
this...
Once upon a time on a project, I saw some interfaces with "I" in front of
them. This was on a project which apparently took it's lead from JLOG,
which does the same thing. I thought it was kind of goofy. "Why prefix it
with 'I'?" I wondered. I decided I didn't like it. My argument was: If
you do your job right, no one should even know that an interface is an
interface. If you define, code to, and use an interface such that it is
indistinguishable from a class, you have succeeded. Why would you want to
draw attention to something that should be transparent? The corollary
being: If the interface represents a Person, why not just call it "Person"?
It makes it clear to the user what it represents, it reads nicely, etc. In
theory, no one ever needs to see "PersonImpl". But, then I started playing
around with Eclipse, and I changed my tune.
In a project the size and scope of Eclipse -- and one with a huge number of
outside observers/users of the code -- having the "I" prefix makes the code
base easier to follow. It makes it clear what you should be using, and
helps you to distinguish the important stuff from the huge number of
behind-the-scenes classes. No confusion between implementors and
interfaces, or between the outward-facing API and the internal details. No
polluting the code with "Impl" postfixes. You always code to the interface,
you always know when you are using an interface, and the line between
"internal" and "API" is more clearly demarcated. So, now I am a fan of the
"I".
Just in case anyone cares :)
-Andrew
"Daniel Megert" <daniel.megert@gmx.net> wrote in message
news:b5pd9t$b3c$1@rogue.oti.com...
> Sebastian Menge wrote:
>
> >>Because some interface may or even have to be implemented by clients
> >>while others are not intended to be implemented. What is confusing you?
> >>
> >>
> >
> >Where are the implementing classes?
> >
> Browser for implementors in the code.
>
> >Where is the need for this convention?
> >
> >People can read Javadoc-API, so they dont need that convention to
recognize
> >"it's an interface", or do I miss something?
> >
> Some people actually prefer to read code rather than Javadoc ;-) If you
> see code like "if (a instance of C)" you do not know if C is an
> interface or class unless you look at the Javadoc.
>
> Dani
>
|
|
| |
| Re: Why that "I*" (IResource, IJavaElement, ...)? [message #595980 is a reply to message #50108] |
Tue, 11 November 2003 09:16 |
| Eclipse User |
|
|
|
Originally posted by: sineyourpitty2000.yahoo.com
Sebastian Menge wrote:
> > Because some interface may or even have to be implemented by clients
> > while others are not intended to be implemented. What is confusing you?
> Where are the implementing classes?
> Where is the need for this convention?
> People can read Javadoc-API, so they dont need that convention to recognize
> "it's an interface", or do I miss something?
> thanks, Sebastian.
Prefixing type qualifiers before a type name (in OO) or variable name is a
convention that sadly endures thanks to the "Hungarian" notation of
variable names and its prevalence in C and C++ code. (see Hungarian
notation, its worth a good laugh)
Remember that only recently did the convention of "short methods" -
(hopefully no more than 12 to 20 lines long) and proper encapsulation even
come into wide practice. In a *short* method, contained in an
appropriately encapsulated class - type qualifiers (on the variable name
or the declared type declaration) are unnecessary because you should be
dealing with objects in a short scope with an obvious meaning and a
transparent algorythm or pattern.
In the case of a "true" convention the "I*" is redundant because if the
coding standard is to *always* code to interfaces then you dont need to
put "I*" before anything. You are *ALWAYS* coding to an interface. So
assume an interface. The time it takes you to check what the factory
actually returns might be worth it -- or not.
Let's also remember that no sane OO programmer is using vi. And that our
wonderful state of the art object browsing development environments will
describe any type declaration with a mere tool tip mouse hover.
Or (optionally) - make friends with C++ cause thats where this really
comes from in my opinion.
I believe it is miopic in nature and is equivalent to the rampant
abbreviation tactics used which obscure the nature of things in software.
It's a time saver which really isnt a time saver because it creates
inconsistencies.
Why does a brain have to identify I before an interface when it doesnt
need to follow the same pattern C for classes and AC for abstract classes.
Carried forward the convention gets ridiculous.
|
|
|
Goto Forum:
Current Time: Fri Dec 27 02:34:57 GMT 2024
Powered by FUDForum. Page generated in 0.04265 seconds |
] 
Search
Help
Register
Login
Home
