Cyclic dependencies are eeeeeeevil
Christian Gruber
I'm incline to have noop completely disallow cyclic dependencies.
Now, this may be accomplished if we say that an implementation class
cannot depend on another implementation class - only a pure interface,
but that interfaces could depend on each other... and I know that some
business models have aggregations and compositions that are cyclic,
but really, they're so eeeeeeevil.
Having said that, perhaps having stronger namespaces so that cycles
can only exist within certain limited zones which are forced to
compile together... I don't know. I guess people will abuse anything,
if they get too lazy to separate packages into small modules.
I am, however, quite serious about impls not being able to depend on
other impls, unless they new them. As in, the compiler won't allow a
variable declaration of a class type.
thoughts? (disregard the extremity of the above, just talk about the
impl/interface bit, since I know we can't really completely do away
with cycles)
Christian.
Ben Rady
Maybe you could try it in early versions and relax the constraint later if it proves too restrictive.
Ben
Christian Edward Gruber
language, and I wasn't serious about that. In a build system, yes,
but not in the language itself.
If you mean it's a strong position to take to not allow variable
declarations to be typed to concrete types, that's actually
recommended Java practice anyway, and isn't that controversial. You
always want to make your variables/attributes take the most abstract
possible type, so your code can accept alternate implementations whose
contract fulfils the abstraction. It's not to say one couldn't still
get it wrong with interfaces, since one can play games with interface
inheritance as well, but it's a step.
Christian.
Christian Edward Gruber
e-mail: christiane...@gmail.com
weblog: http://www.geekinasuit.com/
Ben Rady
Honestly, I don't know enough about noop yet to make a cogent argument here, so I'm not going to try too hard. I would just say that there be danger in trying to correct all of the ills of the Java world in one language.
Ben
Christian Edward Gruber
trying to figure out where it would cost the developer. If we have
special access for test code (which is part of the other proposal),
then the only reason to have access to the concrete type is to
activate methods on that concrete type that aren't available through
the abstraction... but in this case, I'm not sure that's actually
good, outside test code. It encourages stronger dependencies, etc.
I think, as with most things in this language, we'll have to throw up
some sample source and see what shakes out. At least, we should make
it a compiler warning:
WARNING: Variable reference declared for a concrete type.
And the compiler can have options to make that warning an error, just
like other warnings. I just want to provocatively see if we can't
move one step further, and eliminate concrete references. We'll see.
Christian.
AJ
is harder to understand. I like the idea about being the same
namespace, and yes - plenty of lazy people out there. Not matter
what, there are going to be shortcuts but the best you can do is
encourage usage practices and hope for the best. So no multiple
inheritance? :)
On Sep 30, 11:18 pm, Ben Rady <benr...@gmail.com> wrote:
> I'm not saying it's bad, but that's a strong position to take. How does it
> mesh with noop's stated opinions about good and bad practices in software
> development? Are you adding something new to this list by doing that?
>
> Maybe you could try it in early versions and relax the constraint later if
> it proves too restrictive.
>
> Ben
>
Nicolas Dasriaux
Obviously, this thing is better left to an architectural human decision than to a blind digital dictator.
Yes, some tools may help the team to see as quickly as possible the new-born cycles, especially when the code base is getting bigger and bigger...
That might possibly be a WARNING instead of an error...
This may first look as a good idea, but it is probably over-innovation.
For the moment, it is only a vague requirement for the language, you should try a first proof of concept with simple code examples, and the error message displayed by the compiler, if you mean to implement this at the compiler level...
Christian Edward Gruber
we should outlaw all dependency cycles, as I think that would be
impractical, and there are valid models with cycles (mostly in a
business object model mapping to real-world entities and
relationships). I was mostly just complaining about module-level
circular dependencies. Please don't take this one too seriously. The
only idea I'm vaguely serious about from this thread will make its way
into a proposal.
cheers,
Christian.
Christian Edward Gruber
captnmark
be allowed.
Another idea is do disallow / warn on circular dependencies between
namespaces.
On Oct 3, 2:44 am, Christian Edward Gruber
> weblog:http://www.geekinasuit.com/
Christian Edward Gruber
contained, at present, and maybe can't be, if we host on the JVM.
Consider a mavenized app. I can mave module (project) 1, which has
package1 and package2, with no cycles. I have module2 which also has
package1 and package2. Module 2 can depend on package 1, and have a
class in its package2 depend on module1.package2. I can also have
module1.package1 have a dependency on module1.package2. This looks
like cross-namespace dependencies, and it is, but the fact that they
were packaged up in separate jars, and are themselves somewhat
isolated, makes it hard to have namespace be a meaningful boundary.
In fact classloaders with scoping make it a little hard to do this,
without creating certain barriers that would prevent noop code from
interoperating cleanly with other JVM hosted code - (currently) a
project goal.
I still like it, and we've talked a bit about having some sort of
component/module boundary (and I think that would be appropriate for
this limitation) but we haven't gotten down to brass tacks on how it
would work.
Christian.