Talking in terms of popular oop languages like java and c#.
Oop was principally invented to,among other things, prevent code duplication. It is taught tht it has achieved ths objective well, but in reality i dnt think so. As a programmer after wrtg lots of code, code duplication, for the sake of pragmatism becomes inevitable.
And this is because of the oop philosophy of "everything is an object".
Example.

Assumg u have 5 classes under a package. And u want to use the method, "isNull" where isNull = isNull(Object ob); returns a boolean.
You define "isNull" in one class. To use it in other classes in d package you cud a) use aggregation.
Create a reference to the class tht defines "isNull" . And call isNull.
This solves the problem but waste memory because of creatg new instances. Requires client classes to b in d same package with d class defing d method i.e the host class.
B) compile d host class and place in the system's Path/classpath.
Solves the problem but..
A) the system is creatg a functionality tht shud b natve to d language showg poor desgn choice.
B)code in d class path is visible to all other programs . Not a problem generally but in some cases selectve access is better.
E.g the global code mayb inapplicable in other scenarios.

C) the process of makg d method global is tedious: compile/jar-edit classpath variables-copy some classes to classpath folder.

Most programmers would rather duplicate d function in other classes or instantiate the host . Both options ar suboptimal inelegant and wasteful to sat d least.

C) make the method static in the host class this way the function can b accessed without wastng memory.
Wrks but only classes within d package can access it. If get lower,create a sub package the issue snowballs. You have to make the class public to use in sub packages-this is ugly.
The access shud treacle dwn without exposg classes to outsiders.
Explicit Imports have to b made to use the function.
Again, pragmatists may just duplicate d functionality instead of go thru hoops to avoid code duplication.

Finally ,there's d all famous inheritance option.
Other classes can simply extend d host class and use d functionality with ease.
Yeah,this wrks but creates unnecessary relationships.
The clients have to become a subtype ("is-a" to use d function.
Lots of artificial extensions like this are d typical way of re using code in oop.
And messy import has to b explicitly done or d classes have to b in same package as d host class.

Anoda option i think wud b to simply make the namespace object take on some smarts instead of simply being a class partitiong tool.
E.g
if isNull where in a package named "somepkg",
somepkg is a namespace holdg 5 classes.
This is a "is-in" relationship.
Since the 5 classes ar in the package, they cud enjoy servces from the package without being d package. This is a relationship that exists in real life but isnt modelled properly in oop. E.g if citizens are in a bomb shelter , they are not d bombshelter but enjoy its (servce) automatically as a result of the "is-in" relationship.
At the code level, if "isNull" were moved into the package "somepkg" all the classes in d package can then access it. No more messing with class path .
Necessity requires tht all global functions and attributes moved into d package b fixed . So isNull would b static and final /readonly
. That way it will b ensured to behave d consistently wen called.
Also sub packages should b able to automatically call functionality in higher packages.
Under these approach, methods can b global to all members of a package (includg sub packages) and yet be inacessible to external clients. Unlike wat wud b case if the code were placed in d systems classpath.


**This critique is more on d implementation than on oop as a concept.

There is a lot of stuff in your post but if I understand you correctly, you do not like the fact that have to make a class or a method Public to access it from another package.
Because if your isNull method was

public static

when you will avoid wasting memory and it would be accessible to all other classes in your application.
Correct me if I'm wrong but making your class or method public seems to be your beef. Right?

Well I think you have more of a design issue there than anything else. Java is designed to be flexible. There are times when you need a class to be public and other times you may not. If you have a simple utility method like

isNull(Object o) 

that you want to use across your application then what is the point of making it non-public? You want it to be public so you can access it public-ly. That is the whole point.

If however, your

isNull

method is in a class that you have made non-public (protected etc) and you want other classes to use this method, then it has no business being in a non-public class. Create a public utility class and put it in there. Done.

As for using Import statements, there is nothing ugly or verbose about that.

Jeffahead: There is a lot of stuff in your post but if I understand you correctly, you do not like the fact that have to make a class or a method Public to access it from another package.
Because if your isNull method was

public static

when you will avoid wasting memory and it would be accessible to all other classes in your application.
Correct me if I'm wrong but making your class or method public seems to be your beef. Right?

Well I think you have more of a design issue there than anything else. Java is designed to be flexible. There are times when you need a class to be public and other times you may not. If you have a simple utility method like

isNull(Object o) 

that you want to use across your application then what is the point of making it non-public? You want it to be public so you can access it public-ly. That is the whole point.

If however, your

isNull

method is in a class that you have made non-public (protected etc) and you want other classes to use this method, then it has no business being in a non-public class. Create a public utility class and put it in there. Done.

As for using Import statements, there is nothing ugly or verbose about that.

If your class implements

isNull

as static. Classes in the same package can see and use

isNull

.
Let the class implementg

isNull

be the host class and others the client.
If in the course you create a sub package , classes in d sub package cannot use the service ,

isNull

, even though it is static and public.
To use

isNull

,the service, the host is either explicitly imported or put in d classpath.
Since

isNull

is a trvial servce the programmer may just duplicate it.

The programmer needs global functions. In java,the system class path is used to create this but it can b modelled at d code level.

E.g.

package somePkg;
class A {
public static isNull(Object ob){
return ob==null;
}
}

package somePkg;
class B{

public void useObject(Object ob)
{
if(A.isNull(ob))
// do sth

}

package somePkg;
class C{
// c subscribes to A's servce
// for null checks
}

package somePkg.innerPkg;
class D{
//
public boolean validArg(Object ob)
{
// D needs the servce of 'isNull'
but cant get it
without importg A ,
and to do tht A has to b in d class path.
Even D is directly under the same package as A
}
}

package somePkg.innerPkg;
class E{}

E cant use the servce in A too.

Alternatve.
Make d package a construct like
'interface', 'class', 'abstract' etc.

package somePkg{

public final isNull(Object ob)
{
return ob==null;
}
}

package somePkg;
class A{
// since A is 'in' the package it can use the services defined in d package.
It enjoys this benefit because it is 'in' the package.

}


package somePkg.pkgInner;
class F {}
F can enjoy servces in its own immediate package - 'pkgInner'
or in higher up pckages 'somePkg'

no need for akward transfers to classpath.
The programmer writes less code.


No need for A or F to extend a class ,inheritance' to use a servce.

Tests like A instanceof somepkg will return false.

The compiler will check if a package is explicitly defined and link members of the package to d servces defined in d package.


It's like inheritance but its not.
E.g if its raing and a persons runs
into a buildg for shelter.
He enjoys dryness simply because he is IN the buildg.
He is not a buildg,which is d relationship , inheritance will
force to b created for him to enjoy the shelter. The servce provided by d buildg is shelter.
It is a global overshadowing servce.
Rooms inside the buildg also enjoy this services from d main buildg.
But so far in oop, packages,namespaces etc are
just for creatg partitions .theyre primitive simple and basc.
In the current oop sense,
people in d buildg will occupy distinct rooms but each person will either have to bring his own umbrella(code duplication) or
shelter under a larger umbrella (static package/public methods)
.
The buildg offers no overhead servces to its occupants!

^^^^^^^^^

Assuming your packages are all part of the same project then a simple Import statement will solve all your problems.

In this case,Havg No import statement wud b better and more intuitive.
With small classes its no issue with lots of classes the savgs can b sinifcant from not writg that statement.each class has to
stick that statement just to use the servce!its ugly and messy.

Move global functions/properties to a suitable place accessible to all.

I also think it wud enrich d design process if explicit constructs ,tht mirror d real wrld from which OOP philosophy is drawn, were baked into d language.
Just like a programmer designing a java program thinks and looks for "is-a"/"type-of" relationships.
And thinks, "i've written code similar to this,let me abstract it"

if d language design cud make him ask "this code is going to b used by many classes and sub classes,(some unrelated) , let me make it global", it wud be enrichg also.
The complexity is going to be at d compiler level.

This post is misleading. What is the most reason people use OOP, You tink it is to avoid duplicating code? Sadly, No. The encapsulation and abstraction benefits has led many people to use it. Clients of an Object being able to use Code without knowing how that code looks like, Hiding implementation details, and providing an interface's motive is clear and Understood. In your words, You mean to say creating instances of an object wastes memory, sadly that's true. and to that you resolve to using static members or classpaths, editing classpaths for a single app that needs it, to me is overkill. Earlier I said the paramount reason people use oop is because of its encapsulation benefit which if used to the best advantage can save a lot of Frustration. Now the question is does static members gurantee that Benefit? Wen u have hundreds of clasz that depends on the implementation of a single static method else where, can u easily change that method's implementation without breaking codes that rely on it? To me, The memory waste encountered wen creating instances is negligible. It is worth it. And maybe u coming from languages like Java, C# and d likes that does garbage collection for u. ppl with a C++ bacground.won't have a problem. In cases as trivial as ur isNull example, u can create an instance of the object containing that method and imediately after accessing the method, discard that instance by setting its value to null. Its that easy....

dsypha: This post is misleading. What is the most reason people use OOP, You tink it is to avoid duplicating code? Sadly, No. The encapsulation and abstraction benefits has led many people to use it. Clients of an Object being able to use Code without knowing how that code looks like, Hiding implementation details, and providing an interface's motive is clear and Understood. In your words, You mean to say creating instances of an object wastes memory, sadly that's true. and to that you resolve to using static members or classpaths, editing classpaths for a single app that needs it, to me is overkill. Earlier I said the paramount reason people use oop is because of its encapsulation benefit which if used to the best advantage can save a lot of Frustration. Now the question is does static members gurantee that Benefit? Wen u have hundreds of clasz that depends on the implementation of a single static method else where, can u easily change that method's implementation without breaking codes that rely on it? To me, The memory waste encountered wen creating instances is negligible. It is worth it. And maybe u coming from languages like Java, C# and d likes that does garbage collection for u. ppl with a C++ bacground.won't have a problem. In cases as trivial as ur isNull example, u can create an instance of the object containing that method and imediately after accessing the method, discard that instance by setting its value to null. Its that easy....

one of d reasons ppl flocked to java from c,c++ was particularly for the purpose of code economy.
A program written in java requires less code than a correspondg c++ code. So economy matters and convenience is addictive.

My point is also about abstraction
. An abstraction tht mirrors real wrld relationships also and increases code economy.

We all create global functions - explicitly in c,c++,php.
Implicitly,in java,c#.
Stict oop makes this impossible.
Not because every function has to be in a class but because the mechanism for accessing and usg functions in other classes is limited.
A) direct instantiation- waste memory
b) static methods - doesnt waste memory but accessors must b in same package. Sub packages require explicit import all d time.
C) system classpath - the most global of all.
But is not a language fature.
The idea is to make what programmer's make their classpath do a language feature.
If done, less code will b placed in system classpath just to make a servce global.
Then "pragmatic" programmers simply ignore oop rules and do what works - duplicate small portions of code instead of go thru clumsy inheritance or imports.

@kambo
Java does not have globally defined functions. It uses Import statements which is a more concise solution. It creates clarity and avoids confusion. For example, imagine you had a globally defined method called isNull() and you bring in some 3rd party code which also has a globally defined utility method called isNull(). When some code calls isNull() which one of the two global methods will it use? The first one on the stack? Then you'll need to get into classpath ordering at the application level to ensure that the right functionality is used at the method level. The result would unfortunately be chaotic.

So simple Import statements give very clear and strong references to classes that you want to use and with these, you can use as many different methods with the same name as you like in the same class.

Also, your write up about messing around with application level classpath issues to get around writing simple Import statements makes me wonder if your priorities are about building a solution or just experimenting with java.

^^^
the namespace clash u mention will not occur. because the global functions/methods are inside an object -the package construct or artifact.
The classes inside the package access the function as if they personally defined it or inherited it. It is seamless.
If a third party code is brought in with its own global functions,
the only way to access them is by aggregation or inheritance.
Meaning tht to use a method in a 3rd party class you have to use the format :<classname/instance>.methoname
so if the 3rd party implements its own global function it's separated by the path name from those the developer implemented.

If on the other hand the third party code implements its own similar function and d programmer extends the code they will b a clash , but this is not because of a flaw in d concept because it happens in traditional oop also.
Theyre walk arounds. In this case the full canonical name to the function the developer wants to use can b specified. In the format:
<package><function-name>.
The problem goes away.
The clash is namespace issue.
For conciseness, there's nothg virtuous in redundancy. If global functions,at the package level were enabled, a large project wud save on thousands of lines of code from not havg to write import statements.
E,g what if functions like "toString","hashcode" had to be imported bf use? It wud b tiring.
In d same way, if global functions/attributes became integrated .. Programmers seeing the benefit (code economy/ purer relationship) will warm to it.
The java language is still evolvg though i'm usg java here the idea transcends java and applies to OOP languages as a whole.
Lastly, the namespace/packaging structure in oop languages isnt really a theoretical property of oop but a technological convenience.
The buildg block of oop is the class nothg more or less.
Not namespaces or packages.

@kambo

..sign.

What you said is wrong on a number of different levels but I can't tell if you are actually stating what is plainly incorrect or the way you are putting your points across makes them all seem incorrect.

I would ask you to explain further but I get the feeling that if I did your next post may sound even more confusing. What you need to do is put forward your point in a more concise manner. Just a few lines of text and a few lines of solid example code to illustrate the point and then perhaps we can have a technical discussion. Until then, I haven't got the time to spend working out what your post is trying to say and still run the risk of not getting it.

Intelligence isn't about explaining a simple concept in a complicated way, It's about explaining a complicated concept in a simple way.
Try it.

@jeff

Simply sayg i'm confusg doesnt help me know where i'm confusg to you.

I'll try to b clear but i'm not sure i wont come accross as confusing to you.

@jeff ( if you still reading this..)


this is the explanation in code and speech.
but i suspect that the explanation will still be tedious to you.
if so forget it.



a construct is what you create to model a problem with . they are the class,interface,abstract class.

with the global code suggestion a new construct called package would be added. speaking java here.

so you create a class with this syntax:
The words in brackets are used to represent variables instead of using specific names.
instead of saying public or private or package or protected to name an access modifier
i use <access-modifier> etc.

<access-modifier> class <className> {}

e.g

   public class Fruit{}
  public class Book{}

etc..

<access-modifier> = public,private,package etc


same goes for interfaces:

<access-modifier> interface <interfaceName> {}

e.g

 public interface driveAble {}
 publc interface nullchecker{}

if an package construct is introduced. the keyword will be 'package'


rules remain the same:
<access-modifier> package <packageName>{}

in csharp: it the keyword will be 'namespace'

then it would be
<access-modifier> namespace <namespaceName>{}

package and namespace are the same concepts just different names. but i'm using java-speak here.

a programmer creating a typical java class uses the following syntax to
define the package his class belongs to.

package <packageName>;
class <className>{}

but that is all the programmer can do with a package.

with a package construct defined by the programmer, more functionality is given to the package object.
it not just for specifying the name space of the classes and constructs - classes,interfaces etc under it.

e.g

 package somePkg;
  class A{};

A is under the package somePkg.

All somePkg do is hold the classes under it. in current java code.
you can access contents in a package using either the import statement or the full
path of the members of the package.
e.g
the full path of the class A in somePkg is somePkg.A .
in other words , <packageName><className>.

if the package is scripted by the programmer,
the compiler can check for the package construct and link it into the codes using the package at compile time.
e.g

supposing somePkg got scripted. the programmer would do the following..

1.) create the construct 'somePkg' explicitly.
[/code]
package somePkg{}

2.) move global function - methods really into the package.
[code]
 package somePkg
 {
   <access-modifier (either public or package cannot be private or protected) > <methodname>
 }

 i.e
 package somePkg
{
 public isNull(Object ob){return ob==null;}
}

Now A , B , C ... E . infact all top-level classes in the defined package (a defined package is a package
that the programmer explictly scriptd. that is coded in some global functions or fields )
can use the functions in the package without defining them themselves.

e.g

  in class A.
 class A
{
  public method processAnObject(final Object ob){
   //call is null first to check if the argument is valid
      if(isNull(ob)) 
    throw Exception
   else
    // do somthing else.
}
}

 in class B the situation mayb:

 class B
{
 public String[] split(string s){if(isNull(s))return null; else {
 // do something else
}
}
}

All the following classes can write their code using methods in the package.
i.e global functions.
no need for static imports.
no need for inheritance.
less code.
The reason for moving the functions away from the classes is that these functions are so
ubiquitous they are needed by many other classes in the package and so puting them
where they can be easily accessed without using the complex mechanism of inheritance - which
would create artificial relationships - is necessary.

part2:
sub packages.

a subpackage lives within a nother package.

e.g

     somePkg.pkg2;

 pkg2

resides in

somePkg.

pkg2

has classes

F,H,J.

classes F and H may need the method

isNull.

how do they get it.
it is defined in their mother package , i.e the package holding the sub package.

without this function being in a global place . F AND H will have to use either explicit import.


like this: defining classes F,H.

 package somePkg.pkg2;

 import somePkg.A;
 
 class F
{
    public List<?> srr2List(final String[] srr){
      if(A.isNull(srr))return new List<>();
 else
 {
//do something else
}
}
}

The sole reason for the 'import' statement is just to use the service - isNull.

but if the subpackage classes can access global function in higher packages the problem goes away.

the code would be written as:

 public List<?> srr2List(final String[] srr)
{
 if(isNull(srr)) //do sth
 else {//do sth else
  }
}

this is the basic concept.
they are other issues that may arise but they can be ironed out.

issue 1:
----------
what if anoder developer creates a package with a global function similar in name with those defined in
your own package.

the function (method really) defined in a package attaches to all classes that are within the package
or a late binding may occur where the classes only have the function if they actually use it.

say the third party programmer creates

 package thirdParty{isNull(Object ob){}}

and u create

somePkg{isNull(Object ob){})

then

you create a class Z under somePkg that extends a class M in the thirdParty that implements isNull.
conflict arises when Z wants to use isNull and compiler gets confused.

here is what i mean:

 package thirdParty{
 public boolean isNull(Object ob){}
}
 class M
{
 public boolean useObj(final Object o){}
}

 Z extends M
{
  public boolean doSth(Int a){
      if(isNull(a))
      // problem , which isNull is Z calling?
}
}

to resolve the issue , Z can use the canonical path to the function it wants.

 public boolean doSth(Int a)
{
 is(thirdParty.M.isNull(a))
 //
else{}
}

with this the issue is solved.

merits:
--------
a new type of relatiionship is modelled.
an "is-in" relationship.
or "under" relationship.
is this construct i.e class interface etc under a package?
free dom from artificial relationships.

see my previous posts on this.. i dont want to repeat myself.


the is-in relationship exists in nature.
e.g A parasite is in a host. And so enjoys services from the host.
but the parasite is not a type of the host.
in oop the construct to allow service enjoyment is mainly inheritance or aggregation.
in code:

[/code]
class X extends class Y
{
// x enjoys services from y etc
}
[/code]

// aggregation say A has B.

using aggregation it becomes:
[/code]

class X
{
Y y;

public void doSth(){
//invoke code in y.
y.someMethod();
}
}
[/code]

Aggregation says X has Y. e.g
A Book has pages.

But what of somebody hiding out in an embassy for protection from a mob. He enjoys immunity
simply becose of being in the embassy.
inheritance and aggregation doesnt model this.
but global functions can.

--
long explanations.. phew.
--

^^^

So let me get this straight, you are proposing a major rewrite of the Java language all because you don't want to write "import somePkg.A" ??
And you will STILL have to use full canonical names to avoid clashes which is effectively what an import is doing but in a more structured way.

That isn't a very good solution, furthermore it attempts to solve a problem that doesn't even exist. I think there are real weaknesses in Java like it's poor null reference handling, weak type conversion and potential memory leaks.
An import statement however is not a bad thing and If yr app is designed well, you will never ever have to look at classpath manipulation to access other packages in the same application.

I hope before coming up with this critique, you have at the very least worked on creating your own compiler?

@logica
You only need to wear a shoe to know where it pinches.
Not know how it's made bf suggestg improvements.

@jeff

its a big issue.
The import wrk around is unwieldy for large code files .
And do lamguage improvements all require language rewrite. Easy on d exaggeration.
Java 8 is like nothing you've seen bf ,improvement wise. The changes to the language are deep and in one case theyre breaking with legacy code ,did this necessitate a re write?

The idea i air will not break legacy code . It just anoda tool and extension and a minor one at tht.
Infact,unlike genercs where compiler warns about usg untyped collection this concept if implemented wud generate nothg because it is just like inheritance in implementation.
The issue isnt about designing software better or messg with classpath but makg usg a language to express concepts easier.
If a programmer has 100 000
source files in a package and its sub packages requirg a set of typical services ,it is far better to let the servce trckle down to them by virture of theyre being under a particular umbrella , than by writg 100k import statements or creatg some form of often artificial inheritance.
It's simple common sense.

kambo: @logica
You only need to wear a shoe to know where it pinches.
Not know how it's made bf suggestg improvements.

On the contrary, if you know how it is made, then you will realize many of the constraints faced by the designer forcing him to select certain "inefficient" or "uncomfortable" designs.

kambo:
@jeff
its a big issue.
The import wrk around is unwieldy for large code files .
And do lamguage improvements all require language rewrite. Easy on d exaggeration.
Java 8 is like nothing you've seen bf ,improvement wise. The changes to the language are deep and in one case theyre breaking with legacy code ,did this necessitate a re write?
The idea i air will not break legacy code . It just anoda tool and extension and a minor one at tht.
Infact,unlike genercs where compiler warns about usg untyped collection this concept if implemented wud generate nothg because it is just like inheritance in implementation.
The issue isnt about designing software better or messg with classpath but makg usg a language to express concepts easier.
If a programmer has 100 000
source files in a package and its sub packages requirg a set of typical services ,it is far better to let the servce trckle down to them by virture of theyre being under a particular umbrella , than by writg 100k import statements or creatg some form of often artificial inheritance.
It's simple common sense.

You don't have to write 100k import statements. Just use a wildcard silly.
Eg import java.util.*

And before you mention memory, using the wildcard is memory efficient. Problem solved. Again

100 000 source files in different subpackages will requires 100 000 import statements.
sorry problem not solved.

 import java.io.File;

 public class MotherC{

  public void doNada(){}
}
------
class childC extends MotherC
 {
   public void doNada(){
    File f = new File(".";
    File[] frr = f.listFiles();//
      .....
}
}

compiler error:

childC.java:6 error: cannot find symbol
 File f = new File(".";

 childC 

is extending

MotherC

and is in same package as

MotherC

To fix the error i have to include the same import statement in the subclass-

childC

each class/source file must have its own import statement.
2 source files, 2 import statements.
100 000 files, 100 000 import statements. 100 000 extra lines of code.
and import is the only way solve the need for global functions in clases in sub packages.
global functions/fields would reduce number of import statements written for classes in subpackages.

summary:
for non global functions - use import,static fields etc.
for global functions/fields - something more than import is required that saves code and is philosophically sound (oop wise).

kambo: 100 000 source files in different subpackages will requires 100 000 import statements.
sorry problem not solved.

import java.io.File;
public class MotherC{
public void doNada(){}
}
------
class childC extends MotherC
{
public void doNada(){
File f = new File(".";
File[] frr = f.listFiles();//
.....
}
}

compiler error:

childC.java:6 error: cannot find symbol
File f = new File(".";

 childC 

is extending

MotherC

and is in same package as

MotherC

To fix the error i have to include the same import statement in the subclass-

childC

each class/source file must have its own import statement.
2 source files, 2 import statements.
100 000 files, 100 000 import statements. 100 000 extra lines of code.
and import is the only way solve the need for global functions in clases in sub packages.
global functions/fields would reduce number of import statements written for classes in subpackages.
summary:
for non global functions - use import,static fields etc.
for global functions/fields - something more than import is required that saves code and is philosophically sound (oop wise).

You want to have 100,000 source files in 100,000 different sub-packages? Are you insane??

You're right. The problem isn't solved. Because the only problem you have here is extremely terrible design.

Jeffahead:

You want to have 100,000 source files in 100,000 different sub-packages? Are you insane??

You're right. The problem isn't solved. Because the only problem you have here is extremely terrible design.

There you go...

Jeffahead:

You want to have 100,000 source files in 100,000 different sub-packages? Are you insane??

You're right. The problem isn't solved. Because the only problem you have here is extremely terrible design.

Are you insane vs have you heard of large software?
Are you insance or have you heard of N where N is a large number?

are you insane or have you heard of Abstraction?
i could have said N = 100 or 10 000 or 100 000 or 1 000 000 or 1 000 000.
The abstraction remains.
medium/Large application magnify the problem of globalisation using available (crude) tools.

"you want 100 000 source files in 100 000 different source packages" -
where did you get this impression?

I said 100 000 sources in differnt subpackages - meaning the 100 000 (if the app is this large)
reside under 1 package - but they're distributed into different sub packages within the 1 package.
simple.
e.g
in java you have.

javax.swing; javax.swing.text; javax.swing contains javax.swing.text. javax.swing is a package that
contains subpackages and it may contain many sub packages which may contain in themselves sub packages etc and the total files in the main package - javax. could be large e.g 100 000
and all these 100 000 distinct files have only one way to solve global function needs. instantiation -
static referencing, for classes in same package ,else import for classes in differnt packages.

if javax as package held global functions - global to all the members in it. then some of the import statements would be reduced. because the global functions are "seen" by all the members.
less import statement, less code, globalisation issues solved.
I'm patiently going over the point i'm stressing . cuz you're confusing issues.

kambo:
Are you insane vs have you heard of large software?

I've worked on applications with literally millions of lines of code and trust me you never, ever need to have 100,000 import statements. Even 1000 imports in one class is a complete joke and shows serious design issues.

kambo:
I said 100 000 sources in differnt subpackages - meaning the 100 000 (if the app is this large)
reside under 1 package - but they're distributed into different sub packages within the 1 package.
simple.
e.g
in java you have.
javax.swing; javax.swing.text; javax.swing contains javax.swing.text. javax.swing is a package that
contains subpackages and it may contain many sub packages which may contain in themselves sub packages etc and the total files in the main package - javax. could be large e.g 100 000
and all these 100 000 distinct files have only one way to solve global function needs. instantiation -
static referencing, for classes in same package ,else import for classes in differnt packages.
if javax as package held global functions - global to all the members in it. then some of the import statements would be reduced. because the global functions are "seen" by all the members.
less import statement, less code, globalisation issues solved.
I'm patiently going over the point i'm stressing . cuz you're confusing issues.

and like I said, if you have multiple classes in a packages and you just don't feel like writing full import statements for each class because your fingers are tired from posting on NL then use a wildcard. Better still, use a proper IDE that imports stuff for you automagically.

The bottom line is - this is not a problem! OK. Java has issues that have serious effect on development. Issues like type conversion, null referencing, memory leaks and others. These are issues. Suggesting that writing import java.util.List; is an issue just because you don't like to write import statements does not qualify it as important. It is really just your personal gripe. Why if Oracle considered every personal whim of every developer out there then they would be too inundated to put out any releases at all.

Besides, if you have an application where you have to do thousands of import statements in a single class then that is enough to let you know that your application is seriously flawed and you should really look at redesigning and re-factoring into a cleaner code base.

Jeffahead:

I've worked on applications with literally millions of lines of code and trust me you never, ever need to have 100,000 import statements. Even 1000 imports in [b]one class is a complete joke and shows serious design issues.
[/b]



and like I said, if you have multiple classes in a packages and you just don't feel like writing full import statements for each class because your fingers are tired from posting on NL then use a wildcard. Better still, use a proper IDE that imports stuff for you automagically.

The bottom line is - this is not a problem! OK. Java has issues that have serious effect on development. Issues like type conversion, null referencing, memory leaks and others. These are issues. Suggesting that writing import java.util.List; is an issue just because you don't like to write import statements does not qualify it as important. It is really just your personal gripe. Why if Oracle considered every personal whim of every developer out there then they would be too inundated to put out any releases at all.

Besides, if you have an application where you have to do thousands of import statements in a single class then that is enough to let you know that your application is seriously flawed and you should really look at redesigning and re-factoring into a cleaner code base.

you are confusing the issue.
Either you are deliberately being biased or you still dont get what i'm saying.
I am not asking you to support or agree with my point of view but none of your arguments
or criticism shows you even understand my view point.
i am not talking of a class file with 1 000 or 10 000 import statements.
i have never seen a class file with so many import statements even.
so your harping on this shows you dont get me.

here is an example: in code - if you dont get it from here - too bad.


here is a class that holds utility functions for a project.

the project is packaged under the name

somePack

the entire application classes live under that package.

the functions (or methods) that are of generic usage are -

isNull, isNeg

i move them into class

Utility

the code:

 

package somePack;

public class Utility
{
 public static boolean someService(final Object obj)
 {
 //do nothing
  return false;
 }
 
 public static boolean isNull(final Object ob)
 {
  return (ob==null);
 }
 
 public static boolean isNeg(final int n){return n<0;}
}

in the top level package ,i.e the project package there are other classes.

 A,B,C,D

most of these classes require services contained in the utility class and dont want
to rewrite the code - code economy.

so they use of one the available of code usability given their condition- being in same package as
the the class containing the service they need.

The use

Aggregation

instead of inheritance. and to further be more efficient, the methods are made static in the utility class
.

codes:

 classA:

package somePack;

public class A
 {
   
 public String srr2string(final String[] srr)
 {
    if(Utility.isNull(srr))return "";
	else
	{
	//process array
	 return "yada yada yada yada ... ";
	}
   }
 
 public void processNum(final int i)
 {
   if(Utility.isNeg(i))return;
   else
   {
   // do nonthng
   }
 }

 }

 

 class B:
----------
    
package somePack;

public class B
 {
  public int doublePositives(final int i)
   {
    if(Utility.isNeg(i))return -1;
	else
	 return i*2;
   }
}

 class C:
-----------
   
package somePack;

public class C
 {
 
  public int irrSum(final Integer[] intrr){
   if(Utility.isNull(intrr))return -1;
   else
   {
   //sum up the intrr
   return 0;
   }
  }
    public boolean validMoneyAmount(final int i){
	 return !Utility.isNeg(i);
	}
}

 class D:
----------
  
package somePack.subP;

 public class D
 {
      
 }
  
 

There are other classes also in the same package but in sub packages that need the services
provided in the utility class.
For them -

Aggregation

is out of the picture.
How to they get the services needed?

the code:

class E,F

version1:
---------

package somePack.subP;

 public class E
 {
 
  public int negatePositive(int i)
  {
   if(Utility.isNeg(i))return 0;
   else
   {
    return i*-1;
   }
  }
      
 public Object getSimpleName(Object ob)
   {
	   if(Utility.isNull(ob))return "";
	   else
	    return ob.getClass().getSimpleName();
   }
 }



 class F:
--------
     
package somePack.subP;

 public class F
 {
  private String s1,s2;
  public F(final String arg1,final String arg2)
    {
 if(Utility.isNull(arg1)||Utility.isNull(arg2))
 throw new NullPointerException();
  s1=arg1;s2=arg2;
}	

 public String getS1(){return s1;}
 public String getS2(){return s2;}
 }

if you try to compile the program, all the classes in the top Level package will compile.
The classes in the subPackages will not compile.
The classes in the sub packages need the services the classes in the top level subscribe to in
the Utility class.
The only way to get to the access this service , is either to rewrite the code again in the sub package classes - which is trivial inthis case . This leads to code duplication.
or to import the service in. This leads to adding an extra line of code for each source file in sub packages
requiring this service. this is the point i made.
either way - there's waste going on.
if they are N source files below the top level subscribing to a global (global because its functionality is so
ubiquitous. it needed in many places )
function they'll be as many extra statements. leading to N size extra lines of code using the available solution - import.

This is the corrected versions of the classes that work in sub packages.

 E
---
 
package somePack.subP;
import somePack.Utility;// problem solved- via importing
 public class E
 {
 
  public int negatePositive(int i)
  {
   if(Utility.isNeg(i))return 0;
   else
   {
    return i*-1;
   }
  }
      
 public Object getSimpleName(Object ob)
   {
	   if(Utility.isNull(ob))return "";
	   else
	    return ob.getClass().getSimpleName();
   }
 }


  F
----
   
package somePack.subP;
import somePack.Utility;// problem solved - importing

 public class F
 {
  private String s1,s2;
  public F(final String arg1,final String arg2)
    {
 if(Utility.isNull(arg1)||Utility.isNull(arg2))
 throw new NullPointerException();
  s1=arg1;s2=arg2;
}	

 public String getS1(){return s1;}
 public String getS2(){return s2;}
 }

case 2:
--------
in order for sub classes to even use the utility class the Utility must be made completely public,
meaning it is even accessible from any class outside the top level.

YOu maintain that this is not a problem. I say it is a big problem. a sleeper problem that programmers
have gotten used to. But it is still a big problem.
As more sub packages and nested structures enter the program heirarchy the temptation to
write duplicate code will increase , the resentment to write that extra import statement will rise.
That's why ide's are so much an issue here , they mask the bad traits of a language.
An ide could just append the extra ,redundant import statement but better if the language design
were extended to eliminate those statements.

YOu still fail to see what i'm saying. YOu think i'm against using import statements and that i'm
saying what i say because i dont want to write import statements. That's missing the point by a wide
wide margin.
My point is, if global functionality were placed at the top of the heirarchy in a project ,
all members within the heirarchy will access this functionality naturally , they will still use
import statements for the non global functions.
In this case the top heirarchy would be the package construct.
it would hold the functionality , class Utility is created to hold, making the Utility class un necessary
except for providing services to objects outside the package.
Code creation would be simpler and neater. truer to real world oop relationship model.


"What if oracle considered every whim of every developer out there ... "

The merit of an idea is not based on its adoption and even among a collection of viable ideas
a selection of a set amount has to be made . That doesnt mean people shouldnt share or publish
their ideas any more. or stop critiquing present methods for improvement.
Many advancements in the fields of physics,mathematics were built on previous seemingly worthless ideas. if they authors hadnt published their ideas they'd be no advancement.
The theory of relativity by einstein wouldnt have been possible if a former mathematician , didnt criticize
and depart from the then popular model of how spatial dimensions should be percieved.
The world of mathematics is still bemoaning the destruction of some of his works before his death and there's a $1m prize money for anyone who could decipher what the original author intended.
point: dont shoot down your idea whether foolish or sound whether implemented or not . just share and publish.

kambo:

YOu maintain that this is not a problem. I say it is a big problem. a sleeper problem that programmers
have gotten used to. But it is still a big problem.
As more sub packages and nested structures enter the program heirarchy the temptation to
write duplicate code will increase , the resentment to write that extra import statement will rise.
That's why ide's are so much an issue here , they mask the bad traits of a language.
An ide could just append the extra ,redundant import statement but better if the language design
were extended to eliminate those statements.

YOu still fail to see what i'm saying. YOu think i'm against using import statements and that i'm
saying what i say because i dont want to write import statements. That's missing the point by a wide
wide margin.
My point is, if global functionality were placed at the top of the heirarchy in a project ,
all members within the heirarchy will access this functionality naturally , they will still use
import statements for the non global functions.
In this case the top heirarchy would be the package construct.
it would hold the functionality , class Utility is created to hold, making the Utility class un necessary
except for providing services to objects outside the package.
Code creation would be simpler and neater. truer to real world oop relationship model.

Guy, don't over think it. There is no resentment to writing simple import statements and any developer worth their salt would much rather import a method and use it than re-write the whole method again. Anyone who would rather duplicate code than import a method doesn't know what he or she is doing.

I hear what you are saying Kambo. You want more flexibility. I get it. But putting global methods at the top of the package hierarchy instead of just using imports will make applications so flexible that they become more error prone and effectively force developers to over-think their method calls, for example: is the isNull method I am calling in my top end package or in my second to the top-end package? Oh, its in the top end one but I want to use the isNull in the second to the top end package so instead I'll call it by its fully-qualified name. But wait, my colleague has just added another isNull in the package below mine and that is the one I really need - but it is in the package below so I might have to move my code so it is below it... You can imagine the chaos that will follow and developers will definitely start duplicating code because they will want to be sure of what methods they are calling. Essentially, mistakes will be much easier to make because the structure will too flimsy. This is precisely the kind of problems that import statements are designed to solve. Create a public class - in any package or sub-package you like - put your global methods in there and then import it where you need it. Simple and structured. It couldn't be easier.

You can do anything you like if you wanted to write your own compiler, but smarter people than you and I already know how important proper structure is in programming languages. Too much flexibility and the quality of the applications will seriously suffer and the language will be dropped like a piece of hot coal.

^^^
yeah. They cud b clashes and work arounds (full name path) . It will b abused by careless/novice developers no doubt. But for others d convenience cud b compelling.

But beyond d convenience and code economy, i was thinking of how anoda concept, "is-in" besides aggregation (inc. usg imports) and inheritance, cud affect software problem solvg and design.
Well,it's just an idea shared.