Re: [JBoss-dev] Reasons for using Explicit Imports?

2001-06-25 Thread Jason Dillon

It is possible to use an explicit import to resolve conflicts from wildcard
imports, as long as the explicit import is listed after the conflicting
wildcards.

I certain do not suggest that we do this, I just wanted to share =)

--jason


On Sun, 24 Jun 2001, Scott M Stark wrote:

 So you can know what is being used and in general wild card imports
 cannot be used as this causes conflicts when two packages have a
 class with the same name(Attributes for example):

 import javax.naming.directory.*;
 import org.xml.sax.*;

 class tstImport
 {
 public static void main(String[] args)
 {
 Attributes attrs = null;
 }
 }
 bash-2.04$ javac tstImport.java
 tstImport.java:8: reference to Attributes is ambiguous, both class 
org.xml.sax.Attributes in org.xml.sax and class
 javax.naming.directory.Attributes in javax.naming.directory match
 Attributes attrs = null;
 ^
 1 error

 - Original Message -
 From: Matt Veitas [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Sunday, June 24, 2001 6:56 AM
 Subject: [JBoss-dev] Reasons for using Explicit Imports?


 Could you briefly explain the reasoning behind EXPLICIT IMPORTS? What is
 wrong with using wildcards. My guess is that by looking at the explicit
 import list you can have some sense of what exactly is being used or is
 there a performance issue?

 Matt





 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development




___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Reasons for using Explicit Imports?

2001-06-24 Thread Scott M Stark

So you can know what is being used and in general wild card imports
cannot be used as this causes conflicts when two packages have a
class with the same name(Attributes for example):

import javax.naming.directory.*;
import org.xml.sax.*;

class tstImport
{
public static void main(String[] args)
{
Attributes attrs = null;
}
}
bash-2.04$ javac tstImport.java
tstImport.java:8: reference to Attributes is ambiguous, both class 
org.xml.sax.Attributes in org.xml.sax and class
javax.naming.directory.Attributes in javax.naming.directory match
Attributes attrs = null;
^
1 error

- Original Message -
From: Matt Veitas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, June 24, 2001 6:56 AM
Subject: [JBoss-dev] Reasons for using Explicit Imports?


Could you briefly explain the reasoning behind EXPLICIT IMPORTS? What is
wrong with using wildcards. My guess is that by looking at the explicit
import list you can have some sense of what exactly is being used or is
there a performance issue?

Matt





___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] Reasons for using Explicit Imports?

2001-06-24 Thread Hiram Chirino

I feel that t is easier to maintain code that uses explicit imports,  I 
don't have to go hunting to find out in what jar/directory the Foo class 
is at.

Regards,
Hiram

From: Matt Veitas [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Reasons for using Explicit Imports?
Date: Sun, 24 Jun 2001 09:56:21 -0400

Could you briefly explain the reasoning behind EXPLICIT IMPORTS? What is
wrong with using wildcards. My guess is that by looking at the explicit
import list you can have some sense of what exactly is being used or is
there a performance issue?

Matt

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Monday, June 18, 2001 8:02 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Coding conventions



Wonderful...

this should really put us on top of sourceforge at least for the week :)

ok I did add the updated templates (class.java and interface.java) so do
check them out most notably

1- Use the right @author tag to support automatic generation of HTML links
with mail
2- PLEASE UPDATE THE LOG FOR CHANGES **INSIDE** THE CODE... (IMPORTANT AS 
WE
GROW MASSIVE, CVS JUST DOESNT CUT IT)
3- You will also notice a BAN ON TABS! DO NOT use tabs to indent your code
it really screws up the look.  Apache and Linux already enforce the
tabs=2spaces rules, so please configure your IDES to replace tabs by 
2spaces
or go by hand in your code,
4- USE EXPLICIT IMPORTS, I still see some wildcard imports here and there.
We will start taking measure for those of you that don't enforce the
explicit imports rules
5- minor stuff check it out

regards


marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Monday, June 18, 2001 4:01 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/util
|CachePolicy.java ClassPathExtension.java ClassPathExtensionMBean.java
|Executable.java Executor.java ExecutorMBean.java FastKey.java Heap.java
|Info.java InfoMBean.java LRUCachePolicy.java MBeanProxy.jav
|
|
|  User: mnf999
|  Date: 01/06/18 13:01:29
|
|  Modified:src/main/org/jboss/util CachePolicy.java
|ClassPathExtension.java
|ClassPathExtensionMBean.java Executable.java
|Executor.java ExecutorMBean.java FastKey.java
|Heap.java Info.java InfoMBean.java
|LRUCachePolicy.java MBeanProxy.java
|Schedulable.java Scheduler.java 
SchedulerMBean.java
|Semaphore.java Service.java ServiceControl.java
|ServiceControlMBean.java ServiceFactory.java
|ServiceMBean.java ServiceMBeanSupport.java
|Shutdown.java ShutdownMBean.java Sync.java
|SystemProperties.java SystemPropertiesMBean.java
|TimedCachePolicy.java TimerQueue.java
|TimerTask.java WaitSemaphore.java WaitSync.java
|WorkerQueue.java XmlHelper.java
|  Log:
|  Updating the new names and author tags to reflect the new coding
|guidelines
|
|  Revision  ChangesPath
|  1.3   +2 -2  jboss/src/main/org/jboss/util/CachePolicy.java
|
|  Index: CachePolicy.java
|  ===
|  RCS file: 
/cvsroot/jboss/jboss/src/main/org/jboss/util/CachePolicy.java,v
|  retrieving revision 1.2
|  retrieving revision 1.3
|  diff -u -r1.2 -r1.3
|  --- CachePolicy.java2000/12/07 15:45:19 1.2
|  +++ CachePolicy.java2001/06/18 20:01:28 1.3
|  @@ -11,8 +11,8 @@
|* Implementation classes can implement a LRU policy, a random one,
|* a MRU one, or any other suitable policy.
|*
|  - * @author Simone Bordet ([EMAIL PROTECTED])
|  - * @version $Revision: 1.2 $
|  + * @author a href=mailto:[EMAIL PROTECTED];Simone Bordet/a
|  + * @version $Revision: 1.3 $
|*/
|   public interface CachePolicy extends Service
|   {
|
|
|
|  1.11  +1 -1
|jboss/src/main/org/jboss/util/ClassPathExtension.java
|
|  Index: ClassPathExtension.java
|  ===
|  RCS file:
|/cvsroot/jboss/jboss/src/main/org/jboss/util/ClassPathExtension.java,v
|  retrieving revision 1.10
|  retrieving revision 1.11
|  diff -u -r1.10 -r1.11
|  --- ClassPathExtension.java 2001/01/16 21:23:14 1.10
|  +++ ClassPathExtension.java 2001/06/18 20:01:28 1.11
|  @@ -19,8 +19,8 @@
|*   Add URL's to the MLet classloader
|*
|*   @see related
|  - *   @author Rickard Öberg ([EMAIL PROTECTED])
|  - *   @version $Revision: 1.10 $
|  + *   @author a href=mailto:[EMAIL PROTECTED];Rickard
|Öberg/a.
|  + *   @version $Revision: 1.11 $
|*/
|   public class ClassPathExtension
|  implements ClassPathExtensionMBean, MBeanRegistration
|
|
|
|  1.3   +2 -2
|jboss/src/main

Re: [JBoss-dev] Reasons for using Explicit Imports?

2001-06-24 Thread Ole Husgaard

Hi,

Another reason: It makes it easy for the code reader
to quickly find out the package a particular class is
in: You just search for the class name from the start
of the source file.


Best Regards,

Ole Husgaard.


Scott M Stark wrote:
 
 So you can know what is being used and in general wild card imports
 cannot be used as this causes conflicts when two packages have a
 class with the same name(Attributes for example):
 
 import javax.naming.directory.*;
 import org.xml.sax.*;
 
 class tstImport
 {
 public static void main(String[] args)
 {
 Attributes attrs = null;
 }
 }
 bash-2.04$ javac tstImport.java
 tstImport.java:8: reference to Attributes is ambiguous, both class 
org.xml.sax.Attributes in org.xml.sax and class
 javax.naming.directory.Attributes in javax.naming.directory match
 Attributes attrs = null;
 ^
 1 error
 
 - Original Message -
 From: Matt Veitas [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Sunday, June 24, 2001 6:56 AM
 Subject: [JBoss-dev] Reasons for using Explicit Imports?
 
 Could you briefly explain the reasoning behind EXPLICIT IMPORTS? What is
 wrong with using wildcards. My guess is that by looking at the explicit
 import list you can have some sense of what exactly is being used or is
 there a performance issue?
 
 Matt
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-development

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] Reasons for using Explicit Imports?

2001-06-24 Thread marc fleury

Yes that is the real reason.

It is an open source absolute requirement (it is not just, cause it looks
nice).

Open source code is usually REALLY reviewed, meaning that on average at
least 1.5 persons will read your line.

If you did review code you would know why.

Seeing Attributes bla bla bla and not knowing what package it comes from
makes it VERY hard to read, in fact IMPOSSIBLE until you know the actual
full package.  you have to find manually what class that package comes from.
So what are you going to do... well? I can go and search all packages for
ATTRIBUTE  or I can go to the top of the page and see the class.

It is one of those things that you have to do once to really go 'but of
course'...

marcf

|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Ole
|Husgaard
|Sent: Sunday, June 24, 2001 11:29 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Reasons for using Explicit Imports?
|
|
|Hi,
|
|Another reason: It makes it easy for the code reader
|to quickly find out the package a particular class is
|in: You just search for the class name from the start
|of the source file.
|
|
|Best Regards,
|
|Ole Husgaard.
|
|
|Scott M Stark wrote:
|
| So you can know what is being used and in general wild card imports
| cannot be used as this causes conflicts when two packages have a
| class with the same name(Attributes for example):
|
| import javax.naming.directory.*;
| import org.xml.sax.*;
|
| class tstImport
| {
| public static void main(String[] args)
| {
| Attributes attrs = null;
| }
| }
| bash-2.04$ javac tstImport.java
| tstImport.java:8: reference to Attributes is ambiguous, both
|class org.xml.sax.Attributes in org.xml.sax and class
| javax.naming.directory.Attributes in javax.naming.directory match
| Attributes attrs = null;
| ^
| 1 error
|
| - Original Message -
| From: Matt Veitas [EMAIL PROTECTED]
| To: [EMAIL PROTECTED]
| Sent: Sunday, June 24, 2001 6:56 AM
| Subject: [JBoss-dev] Reasons for using Explicit Imports?
|
| Could you briefly explain the reasoning behind EXPLICIT IMPORTS? What is
| wrong with using wildcards. My guess is that by looking at the explicit
| import list you can have some sense of what exactly is being used or is
| there a performance issue?
|
| Matt
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| http://lists.sourceforge.net/lists/listinfo/jboss-development
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development



___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development