Package name should be robotlegs.* not org.robotlegs.* #44

Closed
joelhooks opened this Issue Oct 31, 2011 · 58 comments

Projects

None yet
@joelhooks
Member

Speaking of cruft, is the org really needed? I've taken to dropping the TLD in my general work where I have the choice.

@darscan darscan was assigned Oct 31, 2011
@vrobel
vrobel commented Oct 31, 2011

+1 Good idea, there's a lot of packages beginning with org so would be good to have it in a separate package

@darscan
Member
darscan commented Oct 31, 2011

That reminds me of (the opposite of) this comment:
#43 (comment)

@darscan
Member
darscan commented Oct 31, 2011

..Which I am way behind on. Don't mind me..

@joelhooks
Member

ya, that is what made me think about it. Is Robotlegs an avante guard trend setter? Less cruft for the masses?

@devboy
devboy commented Oct 31, 2011

I do actually prefer longer/descriptive package names like tld.organization.product, but cannot come up with a good reason to support this right now :)

@Stray
Member
Stray commented Oct 31, 2011

For me, it's slightly odd to change it now just for the sake of not having "org.".

There are going to be people mix-n-matching the two, and their packages would end up being weirdly separated by the IDE (when it does the formatting thing).

That said, it would make telling the V1 and V2 packages and classes apart really easy!

@fljot
fljot commented Oct 31, 2011

Vote for shorter version.

It's quite totally unique name, so what the hell... Looks like it becomes quite popular already: spark, starling.

IMHO the only reason for RL to be in some package if you would specify some company in there, like in case of Mate:
com.asfusion.mate...

@darscan
Member
darscan commented Oct 31, 2011

I'm also concerned about the packages being weirdly separated. And as Stray said, it only saves an "org."

@joelhooks
Member

I agree that is different, but I don't think people do a lot of work in the RL namespace. It'd quickly become second nature. It's "only" 4 characters, but they are 4 useless characters.

On Oct 31, 2011, at 17:31, Strayreply@reply.github.com wrote:

For me, it's slightly odd to change it now just for the sake of not having "org.".

There are going to be people mix-n-matching the two, and their packages would end up being weirdly separated by the IDE (when it does the formatting thing).

That said, it would make telling the V1 and V2 packages and classes apart really easy!

Reply to this email directly or view it on GitHub:
#44 (comment)

@Stray
Member
Stray commented Nov 1, 2011

I'm trying to figure out whether there are use cases where you'd have both kinds of packages imported at the same time. Bootstrapping / configuration is the only one I can think of so far.

@darscan
Member
darscan commented Nov 6, 2011

I'm slowly warming to the idea of dropping the "org." (and the "I".. and the "v2"):

robotlegs.core.api.Context

vs

org.robotlegs.v2.core.api.IContext
@joelhooks
Member

So compact and full of relevant info!

On Nov 6, 2011, at 0:38, Shaun Smith
reply@reply.github.com
wrote:

I'm slowly warming to the idea of dropping the "org." (and the "I".. and the "v2"):

robotlegs.core.api.Context

vs

org.robotlegs.v2.core.api.IContext


Reply to this email directly or view it on GitHub:
#44 (comment)

@tschneidereit
Member

+1

@Stray
Member
Stray commented Nov 6, 2011

+0;

I'm not bothered either way - I think it's cleaner, but it also hides a detail that I think should be more explicit. You only know that missing the org. means v2 if you know it (at which point you no longer care)... if you're a newbie to a code base then

org.robotlegs.core.IMediatorMap

vs

robotlegs.extensions.api.IMediatorMap

makes an important distinction implicit.

import paths only matter to people who are unfamiliar with the framework - the rest of us just rely on our IDE doing it for us and mostly they're invisible to us.

But I wouldn't directly object, I just wonder who it benefits vs who it hinders.

Even if we drop the org I think keeping the v2 is instant useful info.

@tschneidereit
Member

Without being able to put it in exact terms, the versioning in the
package name bothers me. It seems like setting in stone something that
really should be an artifact of a temporary transitioning phase.

Maybe that's not bad, and I can see how it makes sense given that
Robotlegs 2 is a complete rewrite instead of just changing some stuff
and adding some more.

On the other hand, part of the semantic versioning concept is
specifically the ability to change up the API without being bound by
backwards compatibility. And I still think that even while staying in
the same package, we'd be able to supply extensions that make a phased
transition possible. Dropping the .org will make that even easier, of
course.

@Stray
Member
Stray commented Nov 6, 2011

I understand that it shouldn't matter from a theoretical point of view, but if I'm a new-to-robotlegs dev picking up a project that contains both swcs, my IDE is going to keep prompting me to choose between two Mediator / Command etc classes. And I think making it more obvious which is v1 and which is v2 is a big plus to a person in that situation, with minimal cost to anyone else.

If we weren't supporting mixing versions in one project then I'd think differently - but given that we are (and I think it's right that we should) then I think we should strive to reduce the confusion that creates.

I know that in theory a person only has to learn that "with the org = v1, without the org = v2" once, but that's not how brains work. I'll happily admit to still having to really think (and from time to time open the docs) to choose between splice/slice and shift/unshift when I'm working with arrays - sadly if something doesn't click the first or second time then it's usually because it has no inherent meaning within our existing understanding of the world and then the confusion firings create just as strong a neural network as the answers.

It's bad enough that in v1 "core" meant "api" and in v2 it now means "things central to the framework"... saying "with the org = v1, without the org = v2" makes me shudder from a new-learner point of view...

I'm guessing that

robotlegs2.extensions.mediatorMap 

is just as unlikable as robotlegs.v2.extensions... ?

@tschneidereit
Member

I do see your point on the naming and cognitive overhead. It's just
pretty unfortunate that we have to set this in stone.

If we keep the version in the package name, I'm strongly in favor of
robotlegs.v2 vs. robotlegs2, though. With the latter, we'd change the
project's name, not only the version. And that would also mean that we
should start at robotlegs2, v1.0.

@Stray
Member
Stray commented Nov 6, 2011

Agreed, robotlegs.v2 is better.

What if version2 had a name instead of a number?

@darscan
Member
darscan commented Nov 6, 2011

robotlegs.bender.core.api.Context

Bender

@tschneidereit
Member

While I'd like that very much personally, I think it would be somewhat irritating for people not hearing the reasoning.

If we went with some kind of name, it definitely would have to be bender.

@Stray
Member
Stray commented Nov 6, 2011

:)

@creynders
Member

What about the trend we're seeing with Chrome and FF, pushing out major versions every 6 weeks? Granted, obviously this won't be the case with RL, but isn't it something to keep in the back of our mind? Just as WHATWG dropping the 5 in HTML and thinking of the HTML specs as a "living" document w/o versioning. It's also what AS3 is evolving to: a dynamic specification with per-class annotations of minor FP version in the docs.
Won't v2 in the package name feel old in two years?

@Stray
Member
Stray commented Nov 8, 2011

@creyenders if the changes are non-breaking, that'll be fine, but breaking changes should be obviously identified IMO - this is what the V2 clearly does for people. It says "this part and this part can play together".

@joelhooks
Member

I will say this, I dislike the .v2 bit, but at least it DOES provide valuable information in certain circumstance. org, not so much.

On Tuesday, November 8, 2011 at 10:55 AM, Stray wrote:

@creyenders if the changes are non-breaking, that'll be fine, but breaking changes should be obviously identified IMO - this is what the V2 clearly does for people. It says "this part and this part can play together".


Reply to this email directly or view it on GitHub:
#44 (comment)

@tschneidereit
Member

Personally, I'm not fond of the explicit versioning in the package name at all.

Unfortunately, I don't see a good way to support gradual upgrades from
RL1 to RL2 without it. And that, in my opinion, is far more important
to achieve.

Hopefully, we should be able to keep the required changes in the next
versions less radical, so we might even be able to drop the versioning
altogether for version 3.

@joelhooks
Member

On Tuesday, November 8, 2011 at 10:58 AM, Till Schneidereit wrote:

Personally, I'm not fond of the explicit versioning in the package name at all.

Unfortunately, I don't see a good way to support gradual upgrades from
RL1 to RL2 without it. And that, in my opinion, is far more important
to achieve.

This is my feeling as well. It is /horrible/ and makes my eyes bleed, but technically it makes some sense. :/

@darscan
Member
darscan commented Nov 8, 2011

And, it's not just about gradual upgrades. It's also about old robotlegs apps being loaded into newer robotlegs shells.

@creynders
Member

@stray I totally agree, I just brought it up because I notice that more and
more systems drop explicit version referencing. TBH I'm not a fan of that
at all.
Bender's really not an option?
:)

On Tue, Nov 8, 2011 at 6:03 PM, Shaun Smith <
reply@reply.github.com>wrote:

And, it's not just about gradual upgrades. It's also about old robotlegs
apps being loaded into newer robotlegs shells.


Reply to this email directly or view it on GitHub:

#44 (comment)

@Daganev
Daganev commented Nov 11, 2011

I agree that v2 is a weird thing to put into a package name, without a plan for v3 in the works. To me, it says that I should wait it out a bit, as this is just a stepping stone.

I think if we get rid of the .org, its a good way to say v2 without committing to a specific version number. robotlegs.bender also works for me. It may not tell me that it is v2 specifically, but it certainly tells me that its not the same project as org.robotlegs, which is all the cognition that I need about it's version status.

Personally, I don't like all my third party apis hiding inside the org folder, I prefer it when they stick out on the root of the directory. According to google, robotlegs is a completely unique thing in the world and doesn't need an org in front to separate it from another namespace.

@Daganev
Daganev commented Nov 11, 2011

And just to re-iterate my point, I don't see any value from "v2" specifically. It's not really telling me what I need to know, it's just an arbitrary marker telling me its not the same as something else.

@Stray
Member
Stray commented Nov 11, 2011

How 'bout

robotlegs.r2d2....

Then the next version can be

robotlegs.c3po

That way we get a name AND a number.

;)

@Daganev
Daganev commented Nov 11, 2011

Genius! :)

@Daganev
Daganev commented Nov 11, 2011

I take that back.. one small problem. r2d2 has no legs! Or maybe, these are it's legs?

@Stray
Member
Stray commented Nov 11, 2011

@Daganev - yes, that was my first response too.

Bender is also easier to say.

My concern is just that if you aren't in on the info then it doesn't say which came before / after. But maybe that shouldn't matter?

I know folk are getting p'd off with the 'Ice Cream Sundae' naming convention for droid, but perhaps we don't have to worry as we won't be doing updates nearly as frequently.

@Daganev
Daganev commented Nov 11, 2011

Which came first or second really doesn't matter at all. The important thing is just that they are different. IMO, just removing the "org." makes the difference loud enough. Although it does run the risk of people thinking that they accidentally put it in the wrong folder. However, the package name in all the classes should make the situation clear. But then what to do in version 3 becomes a question.

@Ondina
Member
Ondina commented Nov 11, 2011

what about:
robotlegs.p0c0
robotlegs.p0c1
robotlegs.p1c2
robotlegs.p2c3 ..and so on
where p is the previous (parent) version and c the current version.

@creynders
Member

I'n definitely in favor of robotlegs.bender

On Fri, Nov 11, 2011 at 2:48 PM, Ondina D.F. <
reply@reply.github.com>wrote:

what about:
robotlegs.p0c0
robotlegs.p0c1
robotlegs.p1c2
robotlegs.p2c3 ..and so on
where p is the previous (parent) version and c the current version.


Reply to this email directly or view it on GitHub:

#44 (comment)

@Ondina
Member
Ondina commented Nov 11, 2011

so version 3 would be robotlegs.bender.unit33 ? ;)

@Ondina
Member
Ondina commented Nov 11, 2011

Stray is right, someone new to rl wouldn’t know what came first, or which version is the chicken and which one the egg and would ask lots of questions about it.
In my opinion it is important to have this info in the package name and also in the name of the swc.
How will you call the swc? robotlegs-bender-framework or robotlegs-framework-bender or just robotlegs-framework-2.0.1?
If I’d use the source then the folders would be:

  • robotlegs-bender
  • swiftsuspenders (or not?)
    I don’t see how it would make sense to have rl1 and rl2 in the same project, but if this can happen, then I think it would be pretty confusing to have org.robotlegs and robotlegs.bender together, unless you make a version of org.robotlegs (rl1) named robotlegs.primordial or something ..
@creynders
Member

@ondina no, I think the idea is that bender=v2. BTW may I suggest robotlegs.batty for v3? With a longevity limited to 4 years of course :)

@joelhooks
Member

This has taken a horrible turn ;)

On Friday, November 11, 2011 at 10:03 AM, Ondina D.F. wrote:

Stray is right, someone new to rl wouldn’t know what came first, or which version is the chicken and which one the egg and would ask lots of questions about it.
In my opinion it is important to have this info in the package name and also in the name of the swc.
How will you call the swc? robotlegs-bender-framework or robotlegs-framework-bender or just robotlegs-framework-2.0.1?
If I’d use the source then the folders would be:

  • robotlegs-bender
  • swiftsuspenders (or not?)
    I don’t see how it would make sense to have rl1 and rl2 in the same project, but if this can happen, then I think it would be pretty confusing to have org.robotlegs and robotlegs.bender together, unless you make a version of org.robotlegs (rl1) named robotlegs.primordial or something ..

Reply to this email directly or view it on GitHub:
#44 (comment)

@creynders
Member

@ondina I think it's about being able to load v1 modules into a v2 shell for instance. Changing the v1 package name is not an option in that case. The reason why I like a totally arbitrary name like bender is exactly because it has no meaning regards the framework, it just identifies a major version, that's it. IMO looking up whether bender came before batty is only done one time and therefore perfectly acceptable to have it in some kind of manifest or readme or whatever.

@creynders
Member

@joelhooks sorry 'bout that :)

@Ondina
Member
Ondina commented Nov 11, 2011

Well, I know that robotlegs.bender=v2, but, see, even if we are talking about the same thing, or so I think;), the questions I asked, will be the questions new comers will ask too
Personally, I don’t care how you name it or which versioning algorithm you'll use:)

@honi
honi commented Nov 11, 2011

Why would a new commer need to know what came first? If you are new, you should be picking up the latest robotlegs release, right? Why would you use legacy code? Why would you have v1 and v2 code mixed up? If it's because of extensions, maybe we can identify all the major extensions out there and ask them if they are willing to port it to v2, so that everything matches up nicely.

And in my case, I don't expect to be using any old stuff. Instead I'm looking forward to porting all my utils to v2 structure anyways.

@srivello

I thought the point of package naming was to manage name collision. Theoretically a 'net.robotlegs' or 'com.robotlegs' could exists, regardless how unlikely. So 'org.robotlegs' is a standard and it prevents, more completely, the naming convention.

I recommend keeping 'org.robotlegs'.

@Stray
Member
Stray commented Nov 11, 2011

@honi if you inherit a codebase that has both, you need to know.

Developers working with someone else's code are my primary concern, because we all know that's a crappy gig before you even start.

Mixing the two is valid because some large codebases will want to take advantage of the new stuff in features being added, without having to update their entire codebase. I've actually got a project like that myself - the test suite alone is about 6000 tests, so there's no way I'm going to update every view and mediator already under test, but I do plan to start using the new Robotlegs stuff asap.

If I go off sick or win the lottery then some other developer is going to have to work with that codebase, and being able to immediately identify whether this IMediator (or Mediator) is from V1 or V2 is useful.

@creynders - sadly brains only retain 'sticky' information, and generally to be sticky something has to have some intrinsic sense or meaning, with respect to things our brains already know. Remembering that bender = v2 is exactly the kind of thing that many brains won't find sticky.

@honi
honi commented Nov 11, 2011

@Stray then in that case I think having "v2" in the package name is the fastest and practical way to know if the Mediator is from v1 or v2. You would still have to look at the imports though (if you are looking at something already coded). And if your coding something new, using a decent IDE, when the auto complete appears you'll easily know if you choosing a v2 or v2 Mediator.

What if your test needs to check something from v1 AND v2? You're gonna end up with explicit lines like org.robotlegs.v2.core.api...

Is it too much overhead to have 2 builds? One with the new package names for new projects, and another one with the "v2" for codebases that need to maintain v1 stuff. And maybe in a future v3 drop the 2 build thing.

Projects like django (djangoproject.com) give you ~2 releases notice of depricated features. Say something is gonna change in a backwards incompatible way in 1.5, so versions 1.3 and 1.4 will give you deprication warnings and support both ways until finally dropping the old stuff.

@Stray
Member
Stray commented Nov 11, 2011

@honi - I don't think that can happen - I've, to date, never written a test that used 2 mediators.

And yes - it's way too messy to have 2 builds - that's just accidents waiting to happen!

@honi
honi commented Nov 11, 2011

Then my +1 goes to removing org, but keeping v2 in the package name, with the intention to permanently remove v2 in a future release when v1 support si no longer really needed (if that every happens).

@Stray
Member
Stray commented Nov 11, 2011

We should be realistic about the fact that changing a package breaks semantic versioning.

So there would be no opportunity to remove v2 until v3 - at which point if there are classes that are untouched it would still be pragmatic to keep the v2 packages in their original location.

Whatever we do, we're likely stuck with it for at least a year or two.

@honi
honi commented Nov 11, 2011

It's like going around in circles! If it's gonna break then, I would just break it now and get on with it.

@Stray
Member
Stray commented Nov 11, 2011

@honi - breaking people's build just because we think a different package name would look more elegant isn't the kind of decision I'd like us to be making.

The opposite, of course, is living with something that looks a bit clunky but actually works. I'm +1 for not shafting developers where we really don't have to.

@darscan
Member
darscan commented Nov 11, 2011

We're not going to be breaking anyone's build. Once a package name has been chosen for a release, it is final for that major version. We can't ever change RL1's public API or package structure. In the Flash world we have to deal with legacy modules (old SWFs) a lot more than in other environments.

Going forward, however, I'm in favour of dropping the org and adopting codenames for major releases. Codenames, in my opinion, are sticky enough. Besides, even today, searching google for "robotlegs bender" brings one straight to this discussion. Any developer who inherits an RL1+2 codebase is going to be smart enough to find the information they need straight away.

The reverse domain naming scheme is really important for projects where the chances of package collisions are high. It is much less important for established projects:

flash.*
spark.*
starling.*
away3d.*
alternativa.*

Robotlegs is fairly well known in the Flash community. I don't think we need to worry about accidental package collisions.

@Stray
Member
Stray commented Nov 11, 2011

In that case, I think we're about to see robotlegs.bender born?

+1 for that - I think it's a more than good enough compromise.

@joelhooks
Member

+1

For namespace collisions the suffix bender is more than sufficient and
provides useful information

On Fri, Nov 11, 2011 at 3:27 PM, Stray
reply@reply.github.com
wrote:

In that case, I think we're about to see robotlegs.bender born?

+1 for that - I think it's a more than good enough compromise.


Reply to this email directly or view it on GitHub:
#44 (comment)

@Daganev
Daganev commented Nov 12, 2011

+1 for robotlegs.bender also as a side comment. I think with Mobile and Desktop and Web projects, seeing more than one build may not become all that uncommon.

@creynders
Member

@stray BTW an alphabetical sequencing scheme could be followed for the codenames: v3 starts with "c", v4 with "d", ... That way it's immediately clear what is the later version. And then bender is definitely the right choice, since v1 should've started with "a"

robotlegs.bender

Love it!

@joelhooks joelhooks closed this in e38f9ca Dec 29, 2011
@darscan darscan reopened this Jan 23, 2012
@darscan darscan closed this Jan 25, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment