Re: Re: import question

On Sat, Mar 14, 2009 at 5:39 AM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Russ" == Russ Paielli <russ.paielli@gmail.com> writes:

 Russ> By the way, it just occurred to me that my suggestion would be
 Russ> superflous if "export" also implies "import." In other words, if
 Russ> export Math._
 Russ> also imports Math._ into the current scope, then it makes my
 Russ> suggested "Import" irrelevant.

It sounds to me like what you really want is:

object Math { ... }

object Mathx extends Math { ... }

which isn't currently allowed, although I seem to recall that the idea
of allowing it has been floated.

Yes, that is true for that particular example. But for other situations it does not apply.

For example, I have a class called Scalar to represent physical scalars. I have another module that instantiates several instances of the Scalar class to represent physical units (meter, second, etc.). The module of units is customized for any particular application or domain, so it cannot simply be part of the Scalar class or package. As Scala currently stands, the client must import both the Scalar module and the units module:

import Scalar._
import MyUnits._

Importing "MyUnits" without also importing "Scalar" makes no sense. If I could "export" the "Scalar" class in "MyUnits," the client would not need to explicitly import it.

Yes, that is a trivial difference, but as a compulsive minimalist I like these kinds of simplifications. 8^)

Russ P.

Why can't you use scala's "type" clause to alleviate your client import problem? Create a file, much like Scala's scala.Predef to do something like:

type Scalar = fully.qualified.path.to.Scalar
type Units = path.to.MyUnits


and then in your client class:

import path.to.ScalarPredef._
val scalarInstance = new Scalar()
val units = new Units()


As for your original idea of using Import, or even the export proposal - I am unsure about its value add to the language.

From what I understand of your requirements - your client class must obviously have to understand not only the types/methods in MyUnits but also the types/methods in Scalar (otherwise you would not need to import both). Given that, I'd say it is better that your client class import them explicitly instead of relying on MyUnits to do the import, since it obviously knows explicitly what Scalar is all about.

Otherwise you have no control over the namespaces that have been implicitly invoked for you. It may not make sense in your particular scenario but I can quite easily imagine a situation where a third party developer writes a class that imports MyUnits and happens to use a another class called Foo. In a later version of Scalar, a class called Foo gets "exported" but this is a different Foo. Without the explicit import in the client class, you now have a situation where changing your export clauses in your Scalar class breaks third-party classes even though their actual code usage of MyUnits' types and signatures are still correct.

I don't know, in such cases I'd prefer the explicit behaviour over your minimilast stance - minimilism is nice but shouldn't come at the cost of ambiguity and code breakage. However, as I said in an earlier post, I am no languate designer, this is just my (possibly flawed) subjective opinion.

Ishaaq



2009/3/16 Russ Paielli <russ.paielli@gmail.com>

On Sat, Mar 14, 2009 at 5:39 AM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Russ" == Russ Paielli <russ.paielli@gmail.com> writes:

 Russ> By the way, it just occurred to me that my suggestion would be
 Russ> superflous if "export" also implies "import." In other words, if
 Russ> export Math._
 Russ> also imports Math._ into the current scope, then it makes my
 Russ> suggested "Import" irrelevant.

It sounds to me like what you really want is:

object Math { ... }

object Mathx extends Math { ... }

which isn't currently allowed, although I seem to recall that the idea
of allowing it has been floated.

Yes, that is true for that particular example. But for other situations it does not apply.

For example, I have a class called Scalar to represent physical scalars. I have another module that instantiates several instances of the Scalar class to represent physical units (meter, second, etc.). The module of units is customized for any particular application or domain, so it cannot simply be part of the Scalar class or package. As Scala currently stands, the client must import both the Scalar module and the units module:

import Scalar._
import MyUnits._

Importing "MyUnits" without also importing "Scalar" makes no sense. If I could "export" the "Scalar" class in "MyUnits," the client would not need to explicitly import it.

Yes, that is a trivial difference, but as a compulsive minimalist I like these kinds of simplifications. 8^)

Russ P.

As a fellow minimalist, however, I am skeptical of features in a
language that cater to narrow corner cases. (And, as an "explicitist",
I never use wild-carded imports. I find value in being clear about
what I am using, and find that if I have a single class that depends
on too many other classes, it may be trying to do too much. ;-)

It seems to me that the proposed feature in question is only relevant
in the case for which A's importing B necessarily entails that A uses
C (some subset of what B uses). That happens sufficiently infrequently
in my code that having a language construct to automate (and hide)
that fact seems excess baggage.

In addition, there's been recent discussion on this list about the
risks of implicit conversions, and the advisability of not relying too
heavily on them. This seems to be subject to the same guidance.

For me, complexity is revealed by the question: "How much (else) to I
have to know to understand this one piece of code I'm reading?" By
this heuristic, having an "implicit import" adds significant
complexity.

-jn-

On Sun, Mar 15, 2009 at 7:09 PM, Russ Paielli wrote:
> Yes, that is true for that particular example. But for other situations it
> does not apply.
>...
> Importing "MyUnits" without also importing "Scalar" makes no sense. If I
> could "export" the "Scalar" class in "MyUnits," the client would not need to
> explicitly import it.
>
> Yes, that is a trivial difference, but as a compulsive minimalist I like
> these kinds of simplifications. 8^)
>
> Russ P.
>

I would be cautious of any system that required you to use the
implicit imports, but from my use cases and what seems to be the case
for Jamies proposal these are entirely optional. If you don't want to
use them you don't have to. They are just meant to help pull in all
of the C's so that people can get up to speed quickly.

I personally always appreciated the idea of a api users #include, that
includes everything necessary for you. Scala also allows you to opt
out of imports and rename them as you see fit.

Also I think it makes a great basis for an IDE feature, import
exportedSymbols._, then code the module then ctrl-o or similar and the
ide makes the implicits explicit. Best of both worlds. -print for non
ide expansion.

On Mon, Mar 16, 2009 at 1:11 PM, Joel Neely wrote:
> As a fellow minimalist, however, I am skeptical of features in a
> language that cater to narrow corner cases. (And, as an "explicitist",
> I never use wild-carded imports. I find value in being clear about
> what I am using, and find that if I have a single class that depends
> on too many other classes, it may be trying to do too much. ;-)
>
> It seems to me that the proposed feature in question is only relevant
> in the case for which A's importing B necessarily entails that A uses
> C (some subset of what B uses). That happens sufficiently infrequently
> in my code that having a language construct to automate (and hide)
> that fact seems excess baggage.
>
> In addition, there's been recent discussion on this list about the
> risks of implicit conversions, and the advisability of not relying too
> heavily on them. This seems to be subject to the same guidance.
>
> For me, complexity is revealed by the question: "How much (else) to I
> have to know to understand this one piece of code I'm reading?" By
> this heuristic, having an "implicit import" adds significant
> complexity.
>
> -jn-
>
> On Sun, Mar 15, 2009 at 7:09 PM, Russ Paielli wrote:
>> Yes, that is true for that particular example. But for other situations it
>> does not apply.
>>...
>> Importing "MyUnits" without also importing "Scalar" makes no sense. If I
>> could "export" the "Scalar" class in "MyUnits," the client would not need to
>> explicitly import it.
>>
>> Yes, that is a trivial difference, but as a compulsive minimalist I like
>> these kinds of simplifications. 8^)
>>
>> Russ P.
>>
>
>
>
> --
> Beauty of style and harmony and grace and good rhythm depend on
> simplicity. - Plato
>

I see an inconsistency.

object Foo { stuff here }
import Foo._

There are objections to the above, but:

class Foo { stuff here }
class Bar extends Foo {
}

In Bar you get everything from Foo, implicitly, but nobody's really
complaining about that.

2009/3/16 Chris Twiner :
> I would be cautious of any system that required you to use the
> implicit imports, but from my use cases and what seems to be the case
> for Jamies proposal these are entirely optional.  If you don't want to
> use them you don't have to.  They are just meant to help pull in all
> of the C's so that people can get up to speed quickly.
>
> I personally always appreciated the idea of a api users #include, that
> includes everything necessary for you.  Scala also allows you to opt
> out of imports and rename them as you see fit.
>
> Also I think it makes a great basis for an IDE feature, import
> exportedSymbols._, then code the module then ctrl-o or similar and the
> ide makes the implicits explicit.  Best of both worlds. -print for non
> ide expansion.
>
> On Mon, Mar 16, 2009 at 1:11 PM, Joel Neely wrote:
>> As a fellow minimalist, however, I am skeptical of features in a
>> language that cater to narrow corner cases. (And, as an "explicitist",
>> I never use wild-carded imports. I find value in being clear about
>> what I am using, and find that if I have a single class that depends
>> on too many other classes, it may be trying to do too much. ;-)
>>
>> It seems to me that the proposed feature in question is only relevant
>> in the case for which A's importing B necessarily entails that A uses
>> C (some subset of what B uses). That happens sufficiently infrequently
>> in my code that having a language construct to automate (and hide)
>> that fact seems excess baggage.
>>
>> In addition, there's been recent discussion on this list about the
>> risks of implicit conversions, and the advisability of not relying too
>> heavily on them. This seems to be subject to the same guidance.
>>
>> For me, complexity is revealed by the question: "How much (else) to I
>> have to know to understand this one piece of code I'm reading?" By
>> this heuristic, having an "implicit import" adds significant
>> complexity.
>>
>> -jn-
>>
>> On Sun, Mar 15, 2009 at 7:09 PM, Russ Paielli wrote:
>>> Yes, that is true for that particular example. But for other situations it
>>> does not apply.
>>>...
>>> Importing "MyUnits" without also importing "Scalar" makes no sense. If I
>>> could "export" the "Scalar" class in "MyUnits," the client would not need to
>>> explicitly import it.
>>>
>>> Yes, that is a trivial difference, but as a compulsive minimalist I like
>>> these kinds of simplifications. 8^)
>>>
>>> Russ P.
>>>
>>
>>
>>
>> --
>> Beauty of style and harmony and grace and good rhythm depend on
>> simplicity. - Plato
>>
>

It depends on your views and use of inheritance. Inheriting an
interface drags in much less baggage than inheriting all
implementation details. It's the latter that concerns me much more.

-jn-

On Mon, Mar 16, 2009 at 7:32 AM, Ricky Clarkson
wrote:
> I see an inconsistency.
>
> object Foo { stuff here }
> import Foo._
>
> There are objections to the above, but:
>
> class Foo { stuff here }
> class Bar extends Foo {
> }
>
> In Bar you get everything from Foo, implicitly, but nobody's really
> complaining about that.
>
> 2009/3/16 Chris Twiner :
>> I would be cautious of any system that required you to use the
>> implicit imports, but from my use cases and what seems to be the case
>> for Jamies proposal these are entirely optional.  If you don't want to
>> use them you don't have to.  They are just meant to help pull in all
>> of the C's so that people can get up to speed quickly.
>>
>> I personally always appreciated the idea of a api users #include, that
>> includes everything necessary for you.  Scala also allows you to opt
>> out of imports and rename them as you see fit.
>>
>> Also I think it makes a great basis for an IDE feature, import
>> exportedSymbols._, then code the module then ctrl-o or similar and the
>> ide makes the implicits explicit.  Best of both worlds. -print for non
>> ide expansion.
>>
>> On Mon, Mar 16, 2009 at 1:11 PM, Joel Neely wrote:
>>> As a fellow minimalist, however, I am skeptical of features in a
>>> language that cater to narrow corner cases. (And, as an "explicitist",
>>> I never use wild-carded imports. I find value in being clear about
>>> what I am using, and find that if I have a single class that depends
>>> on too many other classes, it may be trying to do too much. ;-)
>>>
>>> It seems to me that the proposed feature in question is only relevant
>>> in the case for which A's importing B necessarily entails that A uses
>>> C (some subset of what B uses). That happens sufficiently infrequently
>>> in my code that having a language construct to automate (and hide)
>>> that fact seems excess baggage.
>>>
>>> In addition, there's been recent discussion on this list about the
>>> risks of implicit conversions, and the advisability of not relying too
>>> heavily on them. This seems to be subject to the same guidance.
>>>
>>> For me, complexity is revealed by the question: "How much (else) to I
>>> have to know to understand this one piece of code I'm reading?" By
>>> this heuristic, having an "implicit import" adds significant
>>> complexity.
>>>
>>> -jn-
>>>
>>> On Sun, Mar 15, 2009 at 7:09 PM, Russ Paielli wrote:
>>>> Yes, that is true for that particular example. But for other situations it
>>>> does not apply.
>>>>...
>>>> Importing "MyUnits" without also importing "Scalar" makes no sense. If I
>>>> could "export" the "Scalar" class in "MyUnits," the client would not need to
>>>> explicitly import it.
>>>>
>>>> Yes, that is a trivial difference, but as a compulsive minimalist I like
>>>> these kinds of simplifications. 8^)
>>>>
>>>> Russ P.
>>>>
>>>
>>>
>>>
>>> --
>>> Beauty of style and harmony and grace and good rhythm depend on
>>> simplicity. - Plato
>>>
>>
>

agreed.

On Mon, Mar 16, 2009 at 1:32 PM, Ricky Clarkson
wrote:
> I see an inconsistency.
>
> object Foo { stuff here }
> import Foo._
>
> There are objections to the above, but:
>
> class Foo { stuff here }
> class Bar extends Foo {
> }
>
> In Bar you get everything from Foo, implicitly, but nobody's really
> complaining about that.
>
> 2009/3/16 Chris Twiner :
>> I would be cautious of any system that required you to use the
>> implicit imports, but from my use cases and what seems to be the case
>> for Jamies proposal these are entirely optional.  If you don't want to
>> use them you don't have to.  They are just meant to help pull in all
>> of the C's so that people can get up to speed quickly.
>>
>> I personally always appreciated the idea of a api users #include, that
>> includes everything necessary for you.  Scala also allows you to opt
>> out of imports and rename them as you see fit.
>>
>> Also I think it makes a great basis for an IDE feature, import
>> exportedSymbols._, then code the module then ctrl-o or similar and the
>> ide makes the implicits explicit.  Best of both worlds. -print for non
>> ide expansion.
>>
>> On Mon, Mar 16, 2009 at 1:11 PM, Joel Neely wrote:
>>> As a fellow minimalist, however, I am skeptical of features in a
>>> language that cater to narrow corner cases. (And, as an "explicitist",
>>> I never use wild-carded imports. I find value in being clear about
>>> what I am using, and find that if I have a single class that depends
>>> on too many other classes, it may be trying to do too much. ;-)
>>>
>>> It seems to me that the proposed feature in question is only relevant
>>> in the case for which A's importing B necessarily entails that A uses
>>> C (some subset of what B uses). That happens sufficiently infrequently
>>> in my code that having a language construct to automate (and hide)
>>> that fact seems excess baggage.
>>>
>>> In addition, there's been recent discussion on this list about the
>>> risks of implicit conversions, and the advisability of not relying too
>>> heavily on them. This seems to be subject to the same guidance.
>>>
>>> For me, complexity is revealed by the question: "How much (else) to I
>>> have to know to understand this one piece of code I'm reading?" By
>>> this heuristic, having an "implicit import" adds significant
>>> complexity.
>>>
>>> -jn-
>>>
>>> On Sun, Mar 15, 2009 at 7:09 PM, Russ Paielli wrote:
>>>> Yes, that is true for that particular example. But for other situations it
>>>> does not apply.
>>>>...
>>>> Importing "MyUnits" without also importing "Scalar" makes no sense. If I
>>>> could "export" the "Scalar" class in "MyUnits," the client would not need to
>>>> explicitly import it.
>>>>
>>>> Yes, that is a trivial difference, but as a compulsive minimalist I like
>>>> these kinds of simplifications. 8^)
>>>>
>>>> Russ P.
>>>>
>>>
>>>
>>>
>>> --
>>> Beauty of style and harmony and grace and good rhythm depend on
>>> simplicity. - Plato
>>>
>>
>

On Mon, Mar 16, 2009 at 5:11 AM, Joel Neely <joel.neely@gmail.com> wrote:

As a fellow minimalist, however, I am skeptical of features in a
language that cater to narrow corner cases. (And, as an "explicitist",
I never use wild-carded imports. I find value in being clear about
what I am using, and find that if I have a single class that depends
on too many other classes, it may be trying to do too much. ;-)

I agree about not catering to "narrow corner cases," but I don't think "export" does that. I've been learning Scala for only a couple of months, and I've already found what I consider reasonable uses for it. Like many other features, it can be abused, but that is not necessarily a sufficient reason to ban it.

As for wild-card imports, I think their use is a matter of personal preference as well as the nature of the project being developed. The larger and more critical (safety-critical or mission-critical) the project, the less one should use wild-card imports. In many "safe" environments (e.g., simulation), they are convenient and, I think, acceptable.
 
Russ P.

2009/3/17 Russ Paielli <russ.paielli@gmail.com>

I agree about not catering to "narrow corner cases," but I don't think "export" does that. I've been learning Scala for only a couple of months, and I've already found what I consider reasonable uses for it......

Maybe, but your own words imply that what you consider reasonable may not be what others would call reasonable. I think you are probably biased towards Python's approach towards import while others (me definitely) are biased to Java's approach. The former is used for two things:
1. Finding and initializing a module
2. defining names in the local namespace.

whereas, Java's import is only really used as a convenience shorthand i.e. point number 2 above. You can always use the fully qualified name of a class without resorting to using any imports at all.

Given that behaviour, in Python, you have to import everything that you depend upon in your module both directly and transitively, because you can't run your code without that import statement, whereas in Java this is not necessary - the import is simply syntactic sugar. Consequently, in Python, it would be tedious to have to call separate imports for all your transitive dependencies and so it is convenient for Python to let imports be transitive, Java on the other hand has no compile-time necessity to do so and so there is no need to give you this functionality.

Now we get to the corner case you discuss here, i.e. it is not just a transitive dependency but two direct dependencies of a client class where one also happens to be a direct dependency of the other. Because you are used to Python's necessity in having to import both when you import the one, you now feel that Java's import (which is only namespace specific) is inferior.

However, to somebody like me with  a Java background, Python's approach feels incorrect. As I pointed out earlier, to me, when writing a client class that explicitly deals with both dependencies it feels natural to have to import both types because my code, by definition knows about both. What feels wrong to me is having something imported into my namespace without me knowing about it, causing future source-code incompatibilities without any code changes or incorrect code in my client class - simply a change in the way the libraries I depend on define their "export" behaviour (this is further complicated when the source code for said libraries are unavailable - and so it would not be possible to work out the export behaviour of the classes I depend on).

My reasoning above deals with Java because that is where my experience is based and so, these are my default expectations when I approach a language like Scala. Just pointing out to you that what you call "reasonable" may not universally be so - in fact, to some, it may even be quite unreasonable.

Given that, if you do feel strongly enough about it, as I suggested earlier, using a combination of Scala's type definititions and wildcard imports solves your immediate minimilast requirements without the need for any language changes to scala.

Ishaaq

Yes, I am familiar with the Python approach to importing, and I have never really used Java. That probably  explains my thinking on the matter. In Python, I tend to use lots of wildcard imports, unless I only plan to use one or two items, in which case I sometimes import them explicitly. Only rarely do I use fully qualified names (or "import" not preceded by "from"). That may be sloppy practice, but it is consistent with my minimalist inclinations. I like to see short, crisp lines of code without long, verbose identifiers. But I tend to work relatively independently, and I can set my own coding standards to a large extent.

Scala already has wildcard notation for imports, and I still think it should have "export," although I agree it can be abused. I'll trust the Scala designers to make the right choice.

Speaking of Scala design, one of these days I may ask about the lack of a "continue" statement. That's one thing that really puzzles me about Scala. I used "continue" quite a bit in Python, and adjusting to its absense is no small matter. I assume there is a good reason for not including it in the language, but I am puzzled as to what it could be.

Russ P.


On Mon, Mar 16, 2009 at 8:18 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

2009/3/17 Russ Paielli <russ.paielli@gmail.com>

I agree about not catering to "narrow corner cases," but I don't think "export" does that. I've been learning Scala for only a couple of months, and I've already found what I consider reasonable uses for it......

Maybe, but your own words imply that what you consider reasonable may not be what others would call reasonable. I think you are probably biased towards Python's approach towards import while others (me definitely) are biased to Java's approach. The former is used for two things:
1. Finding and initializing a module
2. defining names in the local namespace.

whereas, Java's import is only really used as a convenience shorthand i.e. point number 2 above. You can always use the fully qualified name of a class without resorting to using any imports at all.

Given that behaviour, in Python, you have to import everything that you depend upon in your module both directly and transitively, because you can't run your code without that import statement, whereas in Java this is not necessary - the import is simply syntactic sugar. Consequently, in Python, it would be tedious to have to call separate imports for all your transitive dependencies and so it is convenient for Python to let imports be transitive, Java on the other hand has no compile-time necessity to do so and so there is no need to give you this functionality.

Now we get to the corner case you discuss here, i.e. it is not just a transitive dependency but two direct dependencies of a client class where one also happens to be a direct dependency of the other. Because you are used to Python's necessity in having to import both when you import the one, you now feel that Java's import (which is only namespace specific) is inferior.

However, to somebody like me with  a Java background, Python's approach feels incorrect. As I pointed out earlier, to me, when writing a client class that explicitly deals with both dependencies it feels natural to have to import both types because my code, by definition knows about both. What feels wrong to me is having something imported into my namespace without me knowing about it, causing future source-code incompatibilities without any code changes or incorrect code in my client class - simply a change in the way the libraries I depend on define their "export" behaviour (this is further complicated when the source code for said libraries are unavailable - and so it would not be possible to work out the export behaviour of the classes I depend on).

My reasoning above deals with Java because that is where my experience is based and so, these are my default expectations when I approach a language like Scala. Just pointing out to you that what you call "reasonable" may not universally be so - in fact, to some, it may even be quite unreasonable.

Given that, if you do feel strongly enough about it, as I suggested earlier, using a combination of Scala's type definititions and wildcard imports solves your immediate minimilast requirements without the need for any language changes to scala.

Ishaaq

--
http://RussP.us

2009/3/17 Russ Paielli <russ.paielli@gmail.com>

Speaking of Scala design, one of these days I may ask about the lack of a "continue" statement. That's one thing that really puzzles me about Scala. I used "continue" quite a bit in Python, and adjusting to its absense is no small matter. I assume there is a good reason for not including it in the language, but I am puzzled as to what it could be.

Here's an old thread about this:

http://www.nabble.com/Any-plans-of-adding-the-break-continue-keywords--td8564005.html#a8596645

Or look here for one possible implementation of break and continue as libraries:

http://gist.github.com/79133

--j

On Mon, Mar 16, 2009 at 11:37 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Yes, I am familiar with the Python approach to importing, and I have never really used Java. That probably  explains my thinking on the matter. In Python, I tend to use lots of wildcard imports, unless I only plan to use one or two items, in which case I sometimes import them explicitly. Only rarely do I use fully qualified names (or "import" not preceded by "from"). That may be sloppy practice, but it is consistent with my minimalist inclinations. I like to see short, crisp lines of code without long, verbose identifiers. But I tend to work relatively independently, and I can set my own coding standards to a large extent.

Scala already has wildcard notation for imports, and I still think it should have "export," although I agree it can be abused. I'll trust the Scala designers to make the right choice.

Speaking of Scala design, one of these days I may ask about the lack of a "continue" statement. That's one thing that really puzzles me about Scala. I used "continue" quite a bit in Python, and adjusting to its absense is no small matter. I assume there is a good reason for not including it in the language, but I am puzzled as to what it could be.

Russ P.


On Mon, Mar 16, 2009 at 8:18 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

2009/3/17 Russ Paielli <russ.paielli@gmail.com>

I agree about not catering to "narrow corner cases," but I don't think "export" does that. I've been learning Scala for only a couple of months, and I've already found what I consider reasonable uses for it......

Maybe, but your own words imply that what you consider reasonable may not be what others would call reasonable. I think you are probably biased towards Python's approach towards import while others (me definitely) are biased to Java's approach. The former is used for two things:
1. Finding and initializing a module
2. defining names in the local namespace.

whereas, Java's import is only really used as a convenience shorthand i.e. point number 2 above. You can always use the fully qualified name of a class without resorting to using any imports at all.

Given that behaviour, in Python, you have to import everything that you depend upon in your module both directly and transitively, because you can't run your code without that import statement, whereas in Java this is not necessary - the import is simply syntactic sugar. Consequently, in Python, it would be tedious to have to call separate imports for all your transitive dependencies and so it is convenient for Python to let imports be transitive, Java on the other hand has no compile-time necessity to do so and so there is no need to give you this functionality.

Now we get to the corner case you discuss here, i.e. it is not just a transitive dependency but two direct dependencies of a client class where one also happens to be a direct dependency of the other. Because you are used to Python's necessity in having to import both when you import the one, you now feel that Java's import (which is only namespace specific) is inferior.

However, to somebody like me with  a Java background, Python's approach feels incorrect. As I pointed out earlier, to me, when writing a client class that explicitly deals with both dependencies it feels natural to have to import both types because my code, by definition knows about both. What feels wrong to me is having something imported into my namespace without me knowing about it, causing future source-code incompatibilities without any code changes or incorrect code in my client class - simply a change in the way the libraries I depend on define their "export" behaviour (this is further complicated when the source code for said libraries are unavailable - and so it would not be possible to work out the export behaviour of the classes I depend on).

My reasoning above deals with Java because that is where my experience is based and so, these are my default expectations when I approach a language like Scala. Just pointing out to you that what you call "reasonable" may not universally be so - in fact, to some, it may even be quite unreasonable.

Given that, if you do feel strongly enough about it, as I suggested earlier, using a combination of Scala's type definititions and wildcard imports solves your immediate minimilast requirements without the need for any language changes to scala.

Ishaaq

--
http://RussP.us

Wow! That is so cool and so wrong all at the same time! :)

Ishaaq

2009/3/17 Jorge Ortiz <jorge.ortiz@gmail.com>

Or look here for one possible implementation of break and continue as libraries:

http://gist.github.com/79133

--j

On Mon, Mar 16, 2009 at 11:37 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Yes, I am familiar with the Python approach to importing, and I have never really used Java. That probably  explains my thinking on the matter. In Python, I tend to use lots of wildcard imports, unless I only plan to use one or two items, in which case I sometimes import them explicitly. Only rarely do I use fully qualified names (or "import" not preceded by "from"). That may be sloppy practice, but it is consistent with my minimalist inclinations. I like to see short, crisp lines of code without long, verbose identifiers. But I tend to work relatively independently, and I can set my own coding standards to a large extent.

Scala already has wildcard notation for imports, and I still think it should have "export," although I agree it can be abused. I'll trust the Scala designers to make the right choice.

Speaking of Scala design, one of these days I may ask about the lack of a "continue" statement. That's one thing that really puzzles me about Scala. I used "continue" quite a bit in Python, and adjusting to its absense is no small matter. I assume there is a good reason for not including it in the language, but I am puzzled as to what it could be.

Russ P.


On Mon, Mar 16, 2009 at 8:18 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

2009/3/17 Russ Paielli <russ.paielli@gmail.com>

I agree about not catering to "narrow corner cases," but I don't think "export" does that. I've been learning Scala for only a couple of months, and I've already found what I consider reasonable uses for it......

Maybe, but your own words imply that what you consider reasonable may not be what others would call reasonable. I think you are probably biased towards Python's approach towards import while others (me definitely) are biased to Java's approach. The former is used for two things:
1. Finding and initializing a module
2. defining names in the local namespace.

whereas, Java's import is only really used as a convenience shorthand i.e. point number 2 above. You can always use the fully qualified name of a class without resorting to using any imports at all.

Given that behaviour, in Python, you have to import everything that you depend upon in your module both directly and transitively, because you can't run your code without that import statement, whereas in Java this is not necessary - the import is simply syntactic sugar. Consequently, in Python, it would be tedious to have to call separate imports for all your transitive dependencies and so it is convenient for Python to let imports be transitive, Java on the other hand has no compile-time necessity to do so and so there is no need to give you this functionality.

Now we get to the corner case you discuss here, i.e. it is not just a transitive dependency but two direct dependencies of a client class where one also happens to be a direct dependency of the other. Because you are used to Python's necessity in having to import both when you import the one, you now feel that Java's import (which is only namespace specific) is inferior.

However, to somebody like me with  a Java background, Python's approach feels incorrect. As I pointed out earlier, to me, when writing a client class that explicitly deals with both dependencies it feels natural to have to import both types because my code, by definition knows about both. What feels wrong to me is having something imported into my namespace without me knowing about it, causing future source-code incompatibilities without any code changes or incorrect code in my client class - simply a change in the way the libraries I depend on define their "export" behaviour (this is further complicated when the source code for said libraries are unavailable - and so it would not be possible to work out the export behaviour of the classes I depend on).

My reasoning above deals with Java because that is where my experience is based and so, these are my default expectations when I approach a language like Scala. Just pointing out to you that what you call "reasonable" may not universally be so - in fact, to some, it may even be quite unreasonable.

Given that, if you do feel strongly enough about it, as I suggested earlier, using a combination of Scala's type definititions and wildcard imports solves your immediate minimilast requirements without the need for any language changes to scala.

Ishaaq

--
http://RussP.us

>
> In Bar you get everything from Foo, implicitly, but nobody's really complaining about that.
>

Doesn't it depend on your definition of "everything"? ;-)

In your example, Foo may have a method fromAaaToBbb that takes an
argument of type Aaa and returns a result of type Bbb. Then users (or
subclasses) of Foo may needs to be aware of Aaa and Bbb. I say "may
need to" because I may be using Foo's other methods without needing
fromAaaToBbb at all.

However, Foo may use values of type Ccc, Ddd, ..., Zzz in its
implementation of fromAaaToBbb, which very much don't want to know (or
care) about. Even worse, Foo's internal use of Yyy may be from a
package that I'm not using at all, but I am using a different package
that does contain a Yyy class. That's why it makes sense that Foo's
import statements (including the one that pulled in Yyy) have nothing
to do with my import statements. At most I only import the parts of
Foo's defined interface that I'm actually using, but I import neither
the implementation details of Foo nor parts of its interface I don't
use.

As for "nobody's really complaining...", I think there are some
implicit complaints in this infamous article:
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

-jn-

On Mon, Mar 16, 2009 at 7:32 AM, Ricky Clarkson
wrote:
> I see an inconsistency.
>
> object Foo { stuff here }
> import Foo._
>
> There are objections to the above, but:
>
> class Foo { stuff here }
> class Bar extends Foo {
> }
>
> In Bar you get everything from Foo, implicitly, but nobody's really
> complaining about that.
>
> 2009/3/16 Chris Twiner :
>> I would be cautious of any system that required you to use the
>> implicit imports, but from my use cases and what seems to be the case
>> for Jamies proposal these are entirely optional.  If you don't want to
>> use them you don't have to.  They are just meant to help pull in all
>> of the C's so that people can get up to speed quickly.
>>
>> I personally always appreciated the idea of a api users #include, that
>> includes everything necessary for you.  Scala also allows you to opt
>> out of imports and rename them as you see fit.
>>
>> Also I think it makes a great basis for an IDE feature, import
>> exportedSymbols._, then code the module then ctrl-o or similar and the
>> ide makes the implicits explicit.  Best of both worlds. -print for non
>> ide expansion.
>>
>> On Mon, Mar 16, 2009 at 1:11 PM, Joel Neely wrote:
>>> As a fellow minimalist, however, I am skeptical of features in a
>>> language that cater to narrow corner cases. (And, as an "explicitist",
>>> I never use wild-carded imports. I find value in being clear about
>>> what I am using, and find that if I have a single class that depends
>>> on too many other classes, it may be trying to do too much. ;-)
>>>
>>> It seems to me that the proposed feature in question is only relevant
>>> in the case for which A's importing B necessarily entails that A uses
>>> C (some subset of what B uses). That happens sufficiently infrequently
>>> in my code that having a language construct to automate (and hide)
>>> that fact seems excess baggage.
>>>
>>> In addition, there's been recent discussion on this list about the
>>> risks of implicit conversions, and the advisability of not relying too
>>> heavily on them. This seems to be subject to the same guidance.
>>>
>>> For me, complexity is revealed by the question: "How much (else) to I
>>> have to know to understand this one piece of code I'm reading?" By
>>> this heuristic, having an "implicit import" adds significant
>>> complexity.
>>>
>>> -jn-
>>>
>>> On Sun, Mar 15, 2009 at 7:09 PM, Russ Paielli wrote:
>>>> Yes, that is true for that particular example. But for other situations it
>>>> does not apply.
>>>>...
>>>> Importing "MyUnits" without also importing "Scalar" makes no sense. If I
>>>> could "export" the "Scalar" class in "MyUnits," the client would not need to
>>>> explicitly import it.
>>>>
>>>> Yes, that is a trivial difference, but as a compulsive minimalist I like
>>>> these kinds of simplifications. 8^)
>>>>
>>>> Russ P.
>>>>
>>>
>>>
>>>
>>> --
>>> Beauty of style and harmony and grace and good rhythm depend on
>>> simplicity. - Plato
>>>
>>
>

2009/3/17 Ishaaq Chandy :
> Wow! That is so cool and so wrong all at the same time! :)

it may be wrong, but it's pretty damn useful. :-)

Mixing it with higher order functions allows some surprisingly neat
techniques. e.g. if you integrated it into Iterable you could have the
following:

List.range(1, 1000).map{x => if (x > 500) break else if (x % 3 != 0)
continue else x / 3 }

Stops building the list when x > 500 and skips everything where x is
not divisible by 3.

Nothing you can't do with a judicious combination of filters and
flatMaps, but potentially a more pleasant way to do things sometimes.