is "export" dead?

Package objects provide similar functionality but require a different coding approach. See Scalaz or Scales Xml for contained examples.

On 26 May 2011 09:53, "Russ Paielli" <russ [dot] paielli [at] gmail [dot] com> wrote:

A while back there was some discussion about the possibility of adding an "export" statement to Scala. For the record, I'd still like to see it. I have imports like this in my code:

import types._
import mathx._
import Scalar._
import ATMunits._

I realize that wildcard imports are suspect, but I actually think these ones are appropriate since they define types, operators, physical units and such. Then again, maybe my coding style is poor. Whatever. The last import line above is almost always preceded by the first three in my code. As a compulsive minimalist, I think

import ATMunits._

all by itself is much cleaner looking, not to mention less typing. An "export" statement would allow me to do that. Yes, I realize that it may encourage bad habits, but I think there is a legitimate place for it (e.g., DSLs?). I don't see any mention of it in the SID library. Is it dead? Thanks.

--Russ P.

--
http://RussP.us

That's a fairly vague reference. I see that Scalaz allows "single-import access to all functions and implicits provided by the library" with

import scalaz._

import Scalaz._
// profit!

That is the type of end-user convenience I am looking for, but when I try to reverse-engineer it, the implementation doesn't look simple at all.

Here's what I want. Suppose I have a typical import pattern that looks like this:

import Stuff1._
import Stuff2._
import Stuff3._
import Stuff._

I would like to be able to just put

export Stuff1._
export Stuff2._
export Stuff3._

into Stuff, so the end user only has to import one thing, namely

import Stuff._

What I *don't* want is to have to put many lines into Stuff for each item that it exports. In other words, I want this to be simple and convenient, not just for the end user of Stuff, but for me too (the creator of Stuff)! Are you saying that package objects can do that? If so, a simple example would be nice. If it is possible, than certainly an example should be available somewhere on the web. Thanks.

--Russ P.


On Thu, May 26, 2011 at 5:11 AM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:

Package objects provide similar functionality but require a different coding approach. See Scalaz or Scales Xml for contained examples.

On 26 May 2011 09:53, "Russ Paielli" <russ [dot] paielli [at] gmail [dot] com> wrote:

A while back there was some discussion about the possibility of adding an "export" statement to Scala. For the record, I'd still like to see it. I have imports like this in my code:

import types._
import mathx._
import Scalar._
import ATMunits._

I realize that wildcard imports are suspect, but I actually think these ones are appropriate since they define types, operators, physical units and such. Then again, maybe my coding style is poor. Whatever. The last import line above is almost always preceded by the first three in my code. As a compulsive minimalist, I think

import ATMunits._

all by itself is much cleaner looking, not to mention less typing. An "export" statement would allow me to do that. Yes, I realize that it may encourage bad habits, but I think there is a legitimate place for it (e.g., DSLs?). I don't see any mention of it in the SID library. Is it dead? Thanks.

--Russ P.

--
http://RussP.us

--
http://RussP.us

While this might be a good idea in principle, you should always keep in mind that your users might not share your definition of “convenience”. The imports are not needed for correct function of Stuff._, so I may take the conscious decision not to import Stuff1._ and instead write that part differently. If Stuff1._ comes automatically with Stuff._, how do I opt-out of the implicit import?
On May 27, 2011, at 00:58 , Russ Paielli wrote:

That's a fairly vague reference. I see that Scalaz allows "single-import access to all functions and implicits provided by the library" with

import scalaz._

import Scalaz._
// profit!

That is the type of end-user convenience I am looking for, but when I try to reverse-engineer it, the implementation doesn't look simple at all.

Here's what I want. Suppose I have a typical import pattern that looks like this:

import Stuff1._
import Stuff2._
import Stuff3._
import Stuff._

I would like to be able to just put

export Stuff1._
export Stuff2._
export Stuff3._

into Stuff, so the end user only has to import one thing, namely

import Stuff._

What I *don't* want is to have to put many lines into Stuff for each item that it exports. In other words, I want this to be simple and convenient, not just for the end user of Stuff, but for me too (the creator of Stuff)! Are you saying that package objects can do that? If so, a simple example would be nice. If it is possible, than certainly an example should be available somewhere on the web. Thanks.

--Russ P.


On Thu, May 26, 2011 at 5:11 AM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:

Package objects provide similar functionality but require a different coding approach. See Scalaz or Scales Xml for contained examples.

On 26 May 2011 09:53, "Russ Paielli" <russ [dot] paielli [at] gmail [dot] com> wrote:

A while back there was some discussion about the possibility of adding an "export" statement to Scala. For the record, I'd still like to see it. I have imports like this in my code:

import types._
import mathx._
import Scalar._
import ATMunits._

I realize that wildcard imports are suspect, but I actually think these ones are appropriate since they define types, operators, physical units and such. Then again, maybe my coding style is poor. Whatever. The last import line above is almost always preceded by the first three in my code. As a compulsive minimalist, I think

import ATMunits._

all by itself is much cleaner looking, not to mention less typing. An "export" statement would allow me to do that. Yes, I realize that it may encourage bad habits, but I think there is a legitimate place for it (e.g., DSLs?). I don't see any mention of it in the SID library. Is it dead? Thanks.

--Russ P.

--
http://RussP.us

--
http://RussP.us

On Thu, May 26, 2011 at 10:38 PM, Roland Kuhn <google [at] rkuhn [dot] info> wrote:

While this might be a good idea in principle, you should always keep in mind that your users might not share your definition of “convenience”. The imports are not needed for correct function of Stuff._, so I may take the conscious decision not to import Stuff1._ and instead write that part differently. If Stuff1._ comes automatically with Stuff._, how do I opt-out of the implicit import?

You have a point. Rather than putting the export statements into an existing file, a more flexible approach is to create new file consisting of export statements only. For example, if I currently have

import Stuff1._
import Stuff2._
import Stuff3._
import Stuff4._
import Stuff._

appearing in several files, I should be able to create another file called Stuffx.scala (x for extended), which contains

export Stuff1._
export Stuff2._
export Stuff3._
export Stuff4._
export Stuff._

Then I can just use

import Stuffx._

and be done with it. Think about how convenient this would be in the REPL, for example. Who wants to type five lines for a quick test when one will do? At the same time, anyone who does not want all those imports would still be free to pick and choose individual imports.

(I CC'd this to scala-debate)

--Russ P.

On May 27, 2011, at 00:58 , Russ Paielli wrote:

That's a fairly vague reference. I see that Scalaz allows "single-import access to all functions and implicits provided by the library" with

import scalaz._

import Scalaz._
// profit!

That is the type of end-user convenience I am looking for, but when I try to reverse-engineer it, the implementation doesn't look simple at all.

Here's what I want. Suppose I have a typical import pattern that looks like this:

import Stuff1._
import Stuff2._
import Stuff3._
import Stuff._

I would like to be able to just put

export Stuff1._
export Stuff2._
export Stuff3._

into Stuff, so the end user only has to import one thing, namely

import Stuff._

What I *don't* want is to have to put many lines into Stuff for each item that it exports. In other words, I want this to be simple and convenient, not just for the end user of Stuff, but for me too (the creator of Stuff)! Are you saying that package objects can do that? If so, a simple example would be nice. If it is possible, than certainly an example should be available somewhere on the web. Thanks.

--Russ P.


On Thu, May 26, 2011 at 5:11 AM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:

Package objects provide similar functionality but require a different coding approach. See Scalaz or Scales Xml for contained examples.

On 26 May 2011 09:53, "Russ Paielli" <russ [dot] paielli [at] gmail [dot] com> wrote:

A while back there was some discussion about the possibility of adding an "export" statement to Scala. For the record, I'd still like to see it. I have imports like this in my code:

import types._
import mathx._
import Scalar._
import ATMunits._

I realize that wildcard imports are suspect, but I actually think these ones are appropriate since they define types, operators, physical units and such. Then again, maybe my coding style is poor. Whatever. The last import line above is almost always preceded by the first three in my code. As a compulsive minimalist, I think

import ATMunits._

all by itself is much cleaner looking, not to mention less typing. An "export" statement would allow me to do that. Yes, I realize that it may encourage bad habits, but I think there is a legitimate place for it (e.g., DSLs?). I don't see any mention of it in the SID library. Is it dead? Thanks.

--Russ P.

--
http://RussP.us

--
http://RussP.us

--
http://RussP.us

On Thu, May 26, 2011 at 10:38 PM, Roland Kuhn <google [at] rkuhn [dot] info> wrote:

While this might be a good idea in principle, you should always keep in mind that your users might not share your definition of “convenience”. The imports are not needed for correct function of Stuff._, so I may take the conscious decision not to import Stuff1._ and instead write that part differently. If Stuff1._ comes automatically with Stuff._, how do I opt-out of the implicit import?

You have a point. Rather than putting the export statements into an existing file, a more flexible approach is to create new file consisting of export statements only. For example, if I currently have

import Stuff1._
import Stuff2._
import Stuff3._
import Stuff4._
import Stuff._

appearing in several files, I should be able to create another file called Stuffx.scala (x for extended), which contains

export Stuff1._
export Stuff2._
export Stuff3._
export Stuff4._
export Stuff._

Then I can just use

import Stuffx._

and be done with it. Think about how convenient this would be in the REPL, for example. Who wants to type five lines for a quick test when one will do? At the same time, anyone who does not want all those imports would still be free to pick and choose individual imports.

(I CC'd this to scala-debate)

--Russ P.

On May 27, 2011, at 00:58 , Russ Paielli wrote:

That's a fairly vague reference. I see that Scalaz allows "single-import access to all functions and implicits provided by the library" with

import scalaz._

import Scalaz._
// profit!

That is the type of end-user convenience I am looking for, but when I try to reverse-engineer it, the implementation doesn't look simple at all.

Here's what I want. Suppose I have a typical import pattern that looks like this:

import Stuff1._
import Stuff2._
import Stuff3._
import Stuff._

I would like to be able to just put

export Stuff1._
export Stuff2._
export Stuff3._

into Stuff, so the end user only has to import one thing, namely

import Stuff._

What I *don't* want is to have to put many lines into Stuff for each item that it exports. In other words, I want this to be simple and convenient, not just for the end user of Stuff, but for me too (the creator of Stuff)! Are you saying that package objects can do that? If so, a simple example would be nice. If it is possible, than certainly an example should be available somewhere on the web. Thanks.

--Russ P.


On Thu, May 26, 2011 at 5:11 AM, Chris Twiner <chris [dot] twiner [at] gmail [dot] com> wrote:

Package objects provide similar functionality but require a different coding approach. See Scalaz or Scales Xml for contained examples.

On 26 May 2011 09:53, "Russ Paielli" <russ [dot] paielli [at] gmail [dot] com> wrote:

A while back there was some discussion about the possibility of adding an "export" statement to Scala. For the record, I'd still like to see it. I have imports like this in my code:

import types._
import mathx._
import Scalar._
import ATMunits._

I realize that wildcard imports are suspect, but I actually think these ones are appropriate since they define types, operators, physical units and such. Then again, maybe my coding style is poor. Whatever. The last import line above is almost always preceded by the first three in my code. As a compulsive minimalist, I think

import ATMunits._

all by itself is much cleaner looking, not to mention less typing. An "export" statement would allow me to do that. Yes, I realize that it may encourage bad habits, but I think there is a legitimate place for it (e.g., DSLs?). I don't see any mention of it in the SID library. Is it dead? Thanks.

--Russ P.

--
http://RussP.us

--
http://RussP.us

--
http://RussP.us

On 05/27/11 15:13, Russ Paielli wrote:
> (...) Rather than putting the export statements into an
> existing file, a more flexible approach is to create new file consisting
> of export statements only. (...) I should be able to create another file
> called Stuffx.scala (x for extended), which contains
>
> export Stuff1._
> export Stuff2._
> export Stuff3._
> export Stuff4._
> export Stuff._
>
> Then I can just use
>
> import Stuffx._
>
> and be done with it. Think about how convenient this would be in the
> REPL, for example.

To have more convenient access to all your Stuff in the REPL, create the file
Stuffx.scala, s/export/import/ and :load Stuffx.scala in the REPL - voila! No
export magic necessary...

:)

-Martin

+1

This is what i do for anything complex before it needs to be a library.

On May 27, 2011 3:31 PM, "Martin S. Weber" <martin [dot] weber [at] nist [dot] gov> wrote:
> On 05/27/11 15:13, Russ Paielli wrote:
>> (...) Rather than putting the export statements into an
>> existing file, a more flexible approach is to create new file consisting
>> of export statements only. (...) I should be able to create another file
>> called Stuffx.scala (x for extended), which contains
>>
>> export Stuff1._
>> export Stuff2._
>> export Stuff3._
>> export Stuff4._
>> export Stuff._
>>
>> Then I can just use
>>
>> import Stuffx._
>>
>> and be done with it. Think about how convenient this would be in the
>> REPL, for example.
>
> To have more convenient access to all your Stuff in the REPL, create the file
> Stuffx.scala, s/export/import/ and :load Stuffx.scala in the REPL - voila! No
> export magic necessary...
>
> :)
>
> -Martin

But :load only works in the REPL, right? Although I mentioned the REPL, it is hardly the main issue here. The proposed solution for the REPL involves creating an import file that is of use only in the REPL. The "export" solution would be work in general, not just in the REPL.

This whole issue is just a matter of convenience. I'd rather type one import line than five, but typing five won't ruin my life. It will just offend my minimalist sensibility.

--Russ P.


On Sat, May 28, 2011 at 6:20 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

+1

This is what i do for anything complex before it needs to be a library.

On May 27, 2011 3:31 PM, "Martin S. Weber" <martin [dot] weber [at] nist [dot] gov> wrote:
> On 05/27/11 15:13, Russ Paielli wrote:
>> (...) Rather than putting the export statements into an
>> existing file, a more flexible approach is to create new file consisting
>> of export statements only. (...) I should be able to create another file
>> called Stuffx.scala (x for extended), which contains
>>
>> export Stuff1._
>> export Stuff2._
>> export Stuff3._
>> export Stuff4._
>> export Stuff._
>>
>> Then I can just use
>>
>> import Stuffx._
>>
>> and be done with it. Think about how convenient this would be in the
>> REPL, for example.
>
> To have more convenient access to all your Stuff in the REPL, create the file
> Stuffx.scala, s/export/import/ and :load Stuffx.scala in the REPL - voila! No
> export magic necessary...
>
> :)
>
> -Martin

--
http://RussP.us

I share Russ's experience that its common to import a bunch of things
together, and some syntactic form that abbreviated that would be
useful.

To me, duplication/boilerplate in imports is undesirable for the same
reasons as in any other code. But the mechanisms for factoring out
duplication of imports seem much weaker than eg code within functions.

@Chris Twiner: Im not sure how package objects can do this? Ive tried
to create package-wide "default imports" and didnt have any success;
imports in a package object are _not_ visible in the associated
package.

-Ben

On Sat, May 28, 2011 at 11:45 PM, Russ Paielli wrote:
> But :load only works in the REPL, right? Although I mentioned the REPL, it
> is hardly the main issue here. The proposed solution for the REPL involves
> creating an import file that is of use only in the REPL. The "export"
> solution would be work in general, not just in the REPL.
>
> This whole issue is just a matter of convenience. I'd rather type one import
> line than five, but typing five won't ruin my life. It will just offend my
> minimalist sensibility.
>
> --Russ P.
>
>
> On Sat, May 28, 2011 at 6:20 AM, Josh Suereth
> wrote:
>>
>> +1
>>
>> This is what i do for anything complex before it needs to be a library.
>>
>> On May 27, 2011 3:31 PM, "Martin S. Weber" wrote:
>> > On 05/27/11 15:13, Russ Paielli wrote:
>> >> (...) Rather than putting the export statements into an
>> >> existing file, a more flexible approach is to create new file
>> >> consisting
>> >> of export statements only. (...) I should be able to create another
>> >> file
>> >> called Stuffx.scala (x for extended), which contains
>> >>
>> >> export Stuff1._
>> >> export Stuff2._
>> >> export Stuff3._
>> >> export Stuff4._
>> >> export Stuff._
>> >>
>> >> Then I can just use
>> >>
>> >> import Stuffx._
>> >>
>> >> and be done with it. Think about how convenient this would be in the
>> >> REPL, for example.
>> >
>> > To have more convenient access to all your Stuff in the REPL, create the
>> > file
>> > Stuffx.scala, s/export/import/ and :load Stuffx.scala in the REPL -
>> > voila! No
>> > export magic necessary...
>> >
>> > :)
>> >
>> > -Martin
>
>
>
> --
> http://RussP.us
>

Sorry all, it was a quick reply made on the phone. I had expected
mentioning package objects with code examples would be enough of a
starter, I should have just waited and made a clearer reply on the
laptop...

Predef also uses this technique and is perhaps the best example for
importing 3rd party code. You must import the things you want to
"export" one by one and perform the following translation (for 3rd
party):

- Every class/type gets a Type in your namespace: type Name = third.party.Name
- Every type needs a type constructor: object Name { def apply ....
- Objects / vals etc can just be mapped 1:1

I.e. lots of boilerplate. For your own code, like Scalaz and Scales
Xml you have more control. The general approach is:

- Define all of your related non class and object code in traits,
implicits in seperate traits, your choice for organisation
- Define a AllImplicits trait or similar and have it extend each of
the implicit traits in your packages **
- Define a XImplicits or (as per Scales Xml and Scalaz capital names)
and extend AllImplitits
- Define a package object that extends each of the other non implicit traits

** Doing this enables the user of the code to just extend your
implicits in one go into their package objects if they choose.

This approach almost guarantees a full compile of your package in most
tools (I'm guessing/hoping that 0.9x sbt can get around this though).

So moral is, if its your own library code you can choose to reorganise
it once and give the benefits to your users (and your own test cases
^_^). However if its 3rd party code, be prepared for some pain for
each import.

I can see obviously see the point for library code doing this, but not
so much for 3rd party.

PS( If you dig far enough back in the lists
(http://scala-programming-language.1934581.n4.nabble.com/Feature-request-...)
you'll find I'm an original requester for such (re-)export
functionality so I'm painfully aware that the current solutions aren't
perfect)

On Sun, May 29, 2011 at 3:43 AM, Ben Hutchison wrote:
> I share Russ's experience that its common to import a bunch of things
> together, and some syntactic form that abbreviated that would be
> useful.
>
> To me, duplication/boilerplate in imports is undesirable for the same
> reasons as in any other code. But the mechanisms for factoring out
> duplication of imports seem much weaker than eg code within functions.
>
> @Chris Twiner: Im not sure how package objects can do this? Ive tried
> to create package-wide "default imports" and didnt have any success;
> imports in a package object are _not_ visible in the associated
> package.
>
> -Ben
>
> On Sat, May 28, 2011 at 11:45 PM, Russ Paielli wrote:
>> But :load only works in the REPL, right? Although I mentioned the REPL, it
>> is hardly the main issue here. The proposed solution for the REPL involves
>> creating an import file that is of use only in the REPL. The "export"
>> solution would be work in general, not just in the REPL.
>>
>> This whole issue is just a matter of convenience. I'd rather type one import
>> line than five, but typing five won't ruin my life. It will just offend my
>> minimalist sensibility.
>>
>> --Russ P.
>>
>>
>> On Sat, May 28, 2011 at 6:20 AM, Josh Suereth
>> wrote:
>>>
>>> +1
>>>
>>> This is what i do for anything complex before it needs to be a library.
>>>
>>> On May 27, 2011 3:31 PM, "Martin S. Weber" wrote:
>>> > On 05/27/11 15:13, Russ Paielli wrote:
>>> >> (...) Rather than putting the export statements into an
>>> >> existing file, a more flexible approach is to create new file
>>> >> consisting
>>> >> of export statements only. (...) I should be able to create another
>>> >> file
>>> >> called Stuffx.scala (x for extended), which contains
>>> >>
>>> >> export Stuff1._
>>> >> export Stuff2._
>>> >> export Stuff3._
>>> >> export Stuff4._
>>> >> export Stuff._
>>> >>
>>> >> Then I can just use
>>> >>
>>> >> import Stuffx._
>>> >>
>>> >> and be done with it. Think about how convenient this would be in the
>>> >> REPL, for example.
>>> >
>>> > To have more convenient access to all your Stuff in the REPL, create the
>>> > file
>>> > Stuffx.scala, s/export/import/ and :load Stuffx.scala in the REPL -
>>> > voila! No
>>> > export magic necessary...
>>> >
>>> > :)
>>> >
>>> > -Martin
>>
>>
>>
>> --
>> http://RussP.us
>>
>

The boiler plate for export is brainless. Is there a great enough need for re-export to formalise this e. G. In a plugin initially?

On 29 May 2011 08:32, "Chris Twiner" <chris [dot] twiner [at] gmail [dot] com> wrote:

Sorry all, it was a quick reply made on the phone.  I had expected
mentioning package objects with code examples would be enough of a
starter, I should have just waited and made a clearer reply on the
laptop...

Predef also uses this technique and is perhaps the best example for
importing 3rd party code.  You must import the things you want to
"export" one by one and perform the following translation (for 3rd
party):

- Every class/type gets a Type in your namespace: type Name = third.party.Name
- Every type needs a type constructor: object Name { def apply ....
- Objects / vals etc can just be mapped 1:1

I.e. lots of boilerplate.  For your own code, like Scalaz and Scales
Xml you have more control.  The general approach is:

- Define all of your related non class and object code in traits,
implicits in seperate traits, your choice for organisation
- Define a AllImplicits trait or similar and have it extend each of
the implicit traits in your packages **
- Define a XImplicits or (as per Scales Xml and Scalaz capital names)
and extend AllImplitits
- Define a package object that extends each of the other non implicit traits

** Doing this enables the user of the code to just extend your
implicits in one go into their package objects if they choose.

This approach almost guarantees a full compile of your package in most
tools (I'm guessing/hoping that 0.9x sbt can get around this though).

So moral is, if its your own library code you can choose to reorganise
it once and give the benefits to your users (and your own test cases
^_^).  However if its 3rd party code, be prepared for some pain for
each import.

I can see obviously see the point for library code doing this, but not
so much for 3rd party.

PS( If you dig far enough back in the lists
(http://scala-programming-language.1934581.n4.nabble.com/Feature-request-syntactic-sugar-for-imports-td1940637i20.html)
you'll find I'm an original requester for such (re-)export
functionality so I'm painfully aware that the current solutions aren't
perfect)

On Sun, May 29, 2011 at 3:43 AM, Ben Hutchison <brhutchison [at] gmail [dot] com> wrote:
> I share Russ's expe...

one way to work around this by not putting the implicits directly in a package object, but in a trait that gets mixed in the package object (or normal object). then you can create 'aggregated implicit imports' with another object that mixes in all necessary trait, so you only have one import in the end

trait LibraryAImplicits {
type A = ...
implicit def xyz ...
def abc ...
}

trait LibraryBImplicits {
type B = ...
implicit def uvw ...
def ghi ...
}

object MyDSL extends LibraryAImplicits with LibraryBImplicits

import MyDSL._ // everything there

And this is the approach Scalaz is taking. I do think this is a fairly simple construct.

The restriction of course is that the libraries are constructed so that you can easily mix in the types and members needed. For example you cannot do that with scala actors, as you cannot mix in object scala.actors.Actor to "import" its members (e.g. 'def actor')... but if you have control over the components, you should be able to construct them with a trait, although i'm not sure this doesn't come with new problems (e.g. you don't have a true singleton any more).

best, -sciss-

On 26 May 2011, at 23:58, Russ Paielli wrote:

> That's a fairly vague reference. I see that Scalaz allows "single-import access to all functions and implicits provided by the library" with
> import scalaz._
>
> import Scalaz._
> // profit!
> That is the type of end-user convenience I am looking for, but when I try to reverse-engineer it, the implementation doesn't look simple at all.
>
> Here's what I want. Suppose I have a typical import pattern that looks like this:
>
> import Stuff1._
> import Stuff2._
> import Stuff3._
> import Stuff._
>
> I would like to be able to just put
>
> export Stuff1._
> export Stuff2._
> export Stuff3._
>
> into Stuff, so the end user only has to import one thing, namely
>
> import Stuff._
>
> What I *don't* want is to have to put many lines into Stuff for each item that it exports. In other words, I want this to be simple and convenient, not just for the end user of Stuff, but for me too (the creator of Stuff)! Are you saying that package objects can do that? If so, a simple example would be nice. If it is possible, than certainly an example should be available somewhere on the web. Thanks.
>
> --Russ P.
>
>
> On Thu, May 26, 2011 at 5:11 AM, Chris Twiner wrote:
> Package objects provide similar functionality but require a different coding approach. See Scalaz or Scales Xml for contained examples.
>
>
>> On 26 May 2011 09:53, "Russ Paielli" wrote:
>>
>> A while back there was some discussion about the possibility of adding an "export" statement to Scala. For the record, I'd still like to see it. I have imports like this in my code:
>>
>> import types._
>> import mathx._
>> import Scalar._
>> import ATMunits._
>>
>> I realize that wildcard imports are suspect, but I actually think these ones are appropriate since they define types, operators, physical units and such. Then again, maybe my coding style is poor. Whatever. The last import line above is almost always preceded by the first three in my code. As a compulsive minimalist, I think
>>
>> import ATMunits._
>>
>> all by itself is much cleaner looking, not to mention less typing. An "export" statement would allow me to do that. Yes, I realize that it may encourage bad habits, but I think there is a legitimate place for it (e.g., DSLs?). I don't see any mention of it in the SID library. Is it dead? Thanks.
>>
>> --Russ P.
>>