I'd throw the shared constants into a separate library imported by both the client code and the server code. If necessary you can also reexport the constants from the client library and the server library.
Cheers,
Kasper
--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
I'd throw the shared constants into a separate library imported by both the client code and the server code. If necessary you can also reexport the constants from the client library and the server library.
Out of curiosity, why is the 'part of' directive required in the source files? Isn't the 'part' ref from the library file enough?
The part declaration in the main library file technically is enough to establish a library (and it used to be like that). The part of declaration serves as a back reference, so that the library and its files are linked from both sides. With that, you immediately know what library you are modifying when you are modifying a file.
That is pretty important, I'd say. The only drawback is that one file can only be a part of one library -- which I think is essentially a good idea.
LTP.S.: AFAIK you can have two libraries with the same name, which lets you put one file into more libraries. I believe that this should only be used for testing, so that the testing code can see _private identifiers.
Am 06.01.2013 13:50 schrieb "Ladislav Thon" <lad...@gmail.com>:
> library and its files are linked from both sides. With that, you immediately know what library you are modifying when you are modifying a file. That is pretty important, I'd say. The only drawback is that one file can only be a part of one library -- which I think is essentially a good idea.
>
The interesting thing here is the notion of what a library _is_ , and what a _part of a library_ is in consequence.
So for every code that would be part of more than one lib we should ask why it is not a lib in itself, making "lib" a more fine grained concept than it may look at first.
When I look into Java land, a "lib" in this sense is a 'jar' file.Sharing code (classes) between jars here is almost always a result of the following
1.) The jars are all part of only one project and created during the same build cycle.
2.) The jars are heavily interrelated, e.g.
A) being a client and server side of one "library" product
B) being a compile-time API vs. a runtime implementation part of a "library" product.
C) being different versions of a "library" product, either timed versions or usage variants.
Each of the mentioned situations in 2. exist because a "library" in form of a jar is understood as being a deploy time packaging-and-delivery artefact, not a development time code separation and reuse artefact.
In the case the latter notion is applied, there is no shared code any more, but OTOH you cannot deliver "one library" any more too. Each deployment is then a bunch of interrelated jars (compare with maven dependencies).
Thus for packaging a product, Java people have invented "ears" or "wars", or whatever package format a specific packaging tool would provide.
The interesting thing here is the notion of what a library _is_ , and what a _part of a library_ is in consequence.
So for every code that would be part of more than one lib we should ask why it is not a lib in itself, making "lib" a more fine grained concept than it may look at first.
When I look into Java land, a "lib" in this sense is a 'jar' file.Sharing code (classes) between jars here is almost always a result of the following
1.) The jars are all part of only one project and created during the same build cycle.
2.) The jars are heavily interrelated, e.g.
A) being a client and server side of one "library" product
B) being a compile-time API vs. a runtime implementation part of a "library" product.
C) being different versions of a "library" product, either timed versions or usage variants.Each of the mentioned situations in 2. exist because a "library" in form of a jar is understood as being a deploy time packaging-and-delivery artefact, not a development time code separation and reuse artefact.
In the case the latter notion is applied, there is no shared code any more, but OTOH you cannot deliver "one library" any more too. Each deployment is then a bunch of interrelated jars (compare with maven dependencies).Thus for packaging a product, Java people have invented "ears" or "wars", or whatever package format a specific packaging tool would provide.
Sounds reasonable but then would it make sense to have an "import show private" directive for testing?
The reason I don't like to make private methods public is not so much that it is "dangerous" but rather that it pollutes the dartdoc.
Yeah. In Dart world, I prefer to think about it like this: library is a unit of code reuse, package is a unit of deployment.
Yeah. In Dart world, I prefer to think about it like this: library is a unit of code reuse, package is a unit of deployment.
Am 08.01.2013 19:00 schrieb "Bob Nystrom" <rnys...@google.com>:
> 2. I think of a package as the unit of reuse. It's actually specifically defined to be that. You can depend on packages. You can't depend on libraries.
>
Please define: You
Please define: depend
Each code importing a library "depends" on said library imho.
Two libraries each importing a third library "reuse" it.
> 3. I think of a package and its transitive dependencies as the unit of deployment. You can't deploy a package without its dependencies. (Well, you can, but it probably won't do much...)
Please define: deploy
Seems we have a bit of different definitions here, where yours might be strongly based on pub perspective?
The way I use 'deploy', it may perhaps better be replaced by 'deliver'?
1. I think of a library as the unit of understanding: To hack on a chunk of code, I think it's reasonable to expect the person to know a bit about the entire library that contains it. (Conversely, I think you should be able to use a library without needing to know much about other libraries in the same package.)
2. I think of a package as the unit of reuse. It's actually specifically defined to be that. You can depend on packages. You can't depend on libraries.
3. I think of a package and its transitive dependencies as the unit of deployment. You can't deploy a package without its dependencies. (Well, you can, but it probably won't do much...)
> 2. I think of a package as the unit of reuse. It's actually specifically defined to be that. You can depend on packages. You can't depend on libraries.
>Please define: You
Please define: depend
Each code importing a library "depends" on said library imho.
Two libraries each importing a third library "reuse" it.
> 3. I think of a package and its transitive dependencies as the unit of deployment. You can't deploy a package without its dependencies. (Well, you can, but it probably won't do much...)
Please define: deploy
Seems we have a bit of different definitions here, where yours might be strongly based on pub perspective?
The way I use 'deploy', it may perhaps better be replaced by 'deliver'?
Allow me to illustrate a more complicated case. Let us say I'd like to provide a library for handling Element. At client side, I can import dart:html. At the server side, I can import html5lib, which provides a nice set of Element, Document, etc.
The only way I can figure out is to use George's approach: include the same source in two different libraries. Unfortunately, it is stopped by Dart compiler now.Any suggestion?
Am 08.01.2013 21:55 schrieb "Bob Nystrom"<rnys...@google.com>:
Thanks ,Bob, for your clarifying definitions.
> True, but there's already a nice word for that "imports". I'd rather not use "depends" to mean the same thing because then it leaves me without a word to express what pub does at the package level.
>
Interesting. I understood "depends" to be a more abstract concept, being more of a _property_ of the dependent code (in the sense of an adjective), while "import" is a more concrete way of how this dependency is solved in the case of libraries, using a verb (could be "use" in other case or "include" in another one).
>> Please define: deploy
>
> Roughly, "make production accessible". In the common case of a web app, that probably means stuffing the app and its dependencies onto some server where it can be served up to a browser.
>>
> If you mean "deliver" in the sense of "send your finished work to some paying client" then, yes, I wouldn't use "deploy" in that sense. But you're right that if someone asks you to make package Foo, you can deliver the goods in that case without having to also send them Foo's dependencies if they can just get those themselves.
>
That was exactly my point!
Bye
Det