[Facets] Goldilocks
Trans
libraries into useful groups. The hope of this is two fold. It should
make development a bit easier and it should make the libs more
accessible to potential users. At first I set out simply to separate
each and every lib into it's own mini-project, but this turned out to
be too fine. So I came at it from the opposite direction, and tried
separating out just the items I was sure should have their own sub-
project. This turned out to be too course --I still had a rather large
motley set remaining. So here I am with my Goldilocks dilemma,
figuring out sub-projects that are "just right".
I've done pretty well so far, but there's still some play I haven't
yet been able to bring to conclusion. So I would like to give a
rundown and see what ideas others might have for putting Goldilocks to
bed. If you look at my subproject directory currently you'll see this:
(I've added some notes of my considerations too)
annotations
aop
bbcode # too versatile to be in markup?
binaryreader # ??? IO-releated?
bitmask # ???
buildingblock
cache
cargo # container classes like PQueue and LinkedList
console
core # core extensions
coroutine # ???
crypt # also includes doublemetaphone
dictionary # move to cargo?
enumerable2 # ???
filesystem
httpaccess
ioredirect # maybe create IO-related subproject?
json # okay to consider this a microformat?
lazy
markup # markup libs like HtmlHelper
math
meta # metaprogramming like overload.rb
microformats # xoxo, hcard, etc.
minis # odd assortment of tiny libs, eg. expirable
multiton
net # network related libs (need better name?)
openobject # maybe in cargo but has three libs
recorder
reflection
rtals
script # rename import, move to meta?
semaphore # ???
snapshot
stateparser
system
tagiterator # move to markup?
timer # ???
tkxml # move to markup?
typecast
units
version_number
As you can see I still have a few (???) that I have no clear idea how
to group, and on a few others I'm debating.
General considerations of the whole affair are welcome too, of course.
T.
_______________________________________________
facets-universal mailing list
facets-u...@rubyforge.org
http://rubyforge.org/mailman/listinfo/facets-universal
Trans
names which other have very technical names. Opinions on which is
best?
Trans
it, the libs start to speak for themselves. It's becoming clear to me
what really needs to happen. And it's very nice I think, but it does
mean a big change. Essentially certain libs "cry out" for there own
package, while others are more at home in a collection. There will be
two main collection projects, one for the extension methods and one
for small/common libs. Then there will be an number of other islet
projects for those that are significant enough. So rather then all of
the libs in a single package they will each have there own packages,
each can be installed independently if you want, and I will use a
package aggregator (which I will write) that will take separate
packages and merge them into a single package, so we can install
everything in one go as we do now too.
I think this is the best way to go. Although it is a big change, it
will make it easier handle the core extensions and the "more"
additions and support external libs just as easily --the whole being a
sort of "best-of-breed" collection, containing the core lib, more lib,
and the other "islet" projects.
This change will require a modified naming scheme. The separated
packages don't have a single package to name, but in general I think
I'll refer to them as the Islets. As for the others, it was tempting
to renaming the whole unified package "Ruby Stars", and just calling
the core lib Facets, but it's probably best to stick with Facets for
the whole. So instead I came up with
core => Corsets
more => Garnets
Of course I suspect I'll hear the suggestion:
core => Core
more => More
But I don't think I want a project that's just called "More". It has
no semantic value in itself. Plus what would I call the Islets?
EvenMore? ;)
In any case, that's the upshot of what's in store for "Facets 2.O".
Trans
Jonathan Buch
> Anyone got a gun? I'm going to shoot Goldilocks and than myself.
uhm... don't... please? ;)
About Corsets and Garnets... I don't really like those names,
and like you suspected the first thing that came to my mind is
'Core'. :P
How about using 'CoreFacets'. :P
But now I get the feeling that the packaging is actually coming
along better now and that it's just the naming problem again.
So, keep up the good work!
Jo
--
Feel the love
http://pinkjuice.com/pics/ruby.png
Trans
On Mar 17, 3:21 pm, "Jonathan Buch" <j...@oxyliquit.de> wrote:
> Hi,
>
> > Anyone got a gun? I'm going to shoot Goldilocks and than myself.
>
> uhm... don't... please? ;)
>
> About Corsets and Garnets... I don't really like those names,
> and like you suspected the first thing that came to my mind is
> 'Core'. :P
> How about using 'CoreFacets'. :P
>
> But now I get the feeling that the packaging is actually coming
> along better now and that it's just the naming problem again.
> So, keep up the good work!
:) It seems you have gotten to know me well. And you are right, it is
coming along. As much as I hate to say it, guns can be good
motivators! ;)
I've actually narrowed it down quite nicely. There will be no more
"more", so
facets/more/multiton -> facets/multiton
As for the core, I am still a bit in debate. I may call the package
"atomix" (or something like that, perhaps, "atom" or "atomics" or
maybe even "atomic_core". Not sure. While I could just call it "core",
I noticed there's already a copycat project out there called
"core_ex". Don't think I want to be perceived as copying them, nor do
I want any confusion between similar projects. In any case, the
require will be either
facets/core/string/plural -> facets/core/string/plural (no
change)
facets/core/string/plural -> facets/atom/string/plural
or
facets/core/string/plural -> facets/string/plural
The later is certainly more convenient. Though the first options would
mean few people will have to change their current require statements.
Thanks for the encouragement,
T.
Trans
conclusion that libs "begging" for there own projects need to have
just that and I moved them out of Facets altogether. When I did that
it became very clear that Facets consisted of the core extensions plus
a set of very basic classes, modules and meta-libs. And the requires
would be okay as:
require "facets/string/plural" # core
require "facets/multiton" # more
Though I still wonder if I should use singular --after all some people
are using this notation with the current version of facets.
require "facet/string/plural"
require "facet/multiton"
The bigger issue however is that while I could have both "core" and
"more" in a single package, it becomes harder to manage and document.
It would be more convenient to have 2 packages. One for the extensions
and another for the additions. One nice thing about this is that you
can depend on the core extensions with out the additions if you don't
need them. But what do I call the second package? Keep in mind, since
the second depends on the first, it would also be the goto package for
installing all of facets in one go. So I was thinking maybe calling it
"facets+". I tested it out and it looks like the "+" character works
on all file systems. Another option is "multifacets", though that does
seem a bit much (reminds me of "Leeloo multi-pass" from the 5th
Element :) Alternatively the first could be called "corefacets" and
the later "facets". My only hesitation here is that I consider "facet"
as basically synonymous with "extension method". So the addition
classes and modules aren't "facets" per se, but, well bonus material.
So the names seem almost backwards to me. But I suppose I'm just being
a stickler for definition here and should give over it.
Anyhow, I'm pretty close. Just these last details to iron out.
Oh, you might be wondering what libs I took out of facets to give
there own projects?... The console tools, rtals, tkxml, the aop-
related libs, httpaccess, units, bbcode, the markup helpers w/
builders, and a few others. These all had either very selective use
cases or were developing into more complex systems --hence the
"begging".
Trans
Option A. Two projects. One is Facets which has two packages, the
extension methods and the basic/general-purpose components. Both can
be installed via one "multi"-package 'facets'. The second project
would contain libs that stand on their own. Unsure of name for this
second project though (Garnets?)
Facets
ace_extensions
ace_components
Garnets (?)
annotations (better in ace_components?)
filesys (better in ace_components?)
markers (xml/xhtml helpers)
tapistry (aop lib)
microfiche (microformat libs)
comrade (commandline lib)
units
flexcache
rtals
bbcode
tkxml
Option B. One Project, Facets, which contains all the libs. The core
extensions package itself would also be called "facets" and the add-on
components would be a different package, though not sure of name for
that (adrets?).
Facets
facets (extensions lib)
adrets (?) (components lib)
annotations (better as component?)
filesys (better as component?)
markers (xml/xhtml helpers)
microfiche (microformat libs)
tapistry (aop lib)
comrade (commandline lib)
units
flexcache
rtals
bbcode
tkxml
Option C. One project (Facets) where the packages are separate but
more tightly coupled name wise. A few packages would need to go in
another project though.
Facets
ace_extensions
ace_components
ace_annotations
ace_filesystem
ace_markups
ace_microformats
ace_aspects
ace_commandline
ace_units
ace_cache
Move to another project
rtals
bbcode
tkxml
Any preference. Any reason to prefer one solution over another?
Thanks,
Olivier Renaud
> I conclude that I have three options. In no particular order:
>
> Option A. Two projects. One is Facets which has two packages, the
> extension methods and the basic/general-purpose components. Both can
> be installed via one "multi"-package 'facets'. The second project
> would contain libs that stand on their own. Unsure of name for this
> second project though (Garnets?)
Hi,
For your interrogation, I'm afraid I don't know enough the components of
Facets, to help you in your decision.
But the name you are thinking about (Garnet) reminded me of a blog post I read
recently about Rubinius. In short, the Rubinius guys will use the name Garnet
to name the dialect of Ruby that generates C code (previously known as Cuby).
Not a good thing to have two Ruby-related projects with the same name :s
Here is the post :
http://on-ruby.blogspot.com/2007/01/serial-rubinius-interview-episode-v.html
--
Olivier Renaud
Trans
On Mar 25, 1:23 pm, Olivier Renaud <o.ren...@laposte.net> wrote:
> Le dimanche 25 mars 2007 18:58, Trans a écrit :
>
> > I conclude that I have three options. In no particular order:
>
> > Option A. Two projects. One is Facets which has two packages, the
> > extension methods and the basic/general-purpose components. Both can
> > be installed via one "multi"-package 'facets'. The second project
> > would contain libs that stand on their own. Unsure of name for this
> > second project though (Garnets?)
> > [...]
>
> Hi,
>
> For your interrogation, I'm afraid I don't know enough the components of
> Facets, to help you in your decision.
>
> But the name you are thinking about (Garnet) reminded me of a blog post I read
> recently about Rubinius. In short, the Rubinius guys will use the name Garnet
> to name the dialect of Ruby that generates C code (previously known as Cuby).
>
> Not a good thing to have two Ruby-related projects with the same name :s
>
> Here is the post :
>
> http://on-ruby.blogspot.com/2007/01/serial-rubinius-interview-episode...
Thanks. I won't use that term for sure then, and instead offer up the
term "Adret". Which is French word (but used sometimes in English)
that means the sunny-side of a mountain (a very big facet ;)
Do you have any opinion on which of these three options would be best
in general / work best for you?
Thanks,
T.
Olivier Renaud
> Thanks. I won't use that term for sure then, and instead offer up the
> term "Adret". Which is French word (but used sometimes in English)
> that means the sunny-side of a mountain (a very big facet ;)
>
> Do you have any opinion on which of these three options would be best
> in general / work best for you?
>
> Thanks,
> T.
Yes I know the word Adret, since I am french :) It's not a very common word,
though. Does the "t" is pronounced in english ? In fench the pronounciation
is "adrè", if the accent makes sense for you.
I have one question : what does the prefix "ace_" mean ?
Also, with the name ace_extensions, there is another gem called extensions
(http://extensions.rubyforge.org), which is somehow similar to what facets
core does. I just discovered it,
Hmm that doesn't answer your question at all ! But I don't really know. About
whether splitting the project in two or not, I don't care. It's more a matter
of simplicity of organization for you, I guess.
For the two main libs, the extensions and the components, I think they should
keep a reference to "facets" in their names. Also, I prefer simple names over
multiples different names (the names Facets/core Facets/more were great for
that, both explicit and simple).
I think the option B is the closest of what I am expecting.
--
Olivier Renaud
Trans
On Mar 26, 6:38 pm, Olivier Renaud <o.ren...@laposte.net> wrote:
> Le dimanche 25 mars 2007 20:16, Trans a écrit :
>
> > Thanks. I won't use that term for sure then, and instead offer up the
> > term "Adret". Which is French word (but used sometimes in English)
> > that means the sunny-side of a mountain (a very big facet ;)
>
> > Do you have any opinion on which of these three options would be best
> > in general / work best for you?
>
> > Thanks,
> > T.
>
> Yes I know the word Adret, since I am french :) It's not a very common word,
> though. Does the "t" is pronounced in english ? In fench the pronounciation
> is "adrè", if the accent makes sense for you.
How coincidental!? :) As for Adret in English, I've seen both
pronunciations. And yes it is a very obscure word.
> I have one question : what does the prefix "ace_" mean ?
The idea is really just to give the different packages cohesion
without over doing it, in the way that "active" and "action" are used
for the parts of Rails. While "facets_" could be used as a prefix,
that obscures the capability of the parts to be used independently of
one another. I thought of "ace" because it can mean small/atomic
units.
> Also, with the name ace_extensions, there is another gem called extensions
> (http://extensions.rubyforge.org), which is somehow similar to what facets
> core does. I just discovered it,
Yes, I've known of the project since it's inception. In fact a number
of facets come from there. A well done project, but much more
conservative than Facets. I've talked to Gavin (the maintainer) on a
number of occasions. It's complimented by his project "additions". But
development trailed off a couple of years ago.
Actually you may not know this. Originally Facets was just the method
extensions. The additional class/modules were in another project
called "Calibre".
> Hmm that doesn't answer your question at all ! But I don't really know. About
> whether splitting the project in two or not, I don't care. It's more a matter
> of simplicity of organization for you, I guess.
>
> For the two main libs, the extensions and the components, I think they should
> keep a reference to "facets" in their names. Also, I prefer simple names over
> multiples different names (the names Facets/core Facets/more were great for
> that, both explicit and simple).
I agree with the simplicity at least. The names are nice but really
say very little. Only the word "core" indicates anything at all about
what it does. In wanting to provide some independent usage to some of
the "more" libs. "more" as a package name starts to fall flat.
> I think the option B is the closest of what I am expecting.
Interesting b/c that seems to be in opposition to your last statement.
Did you actually mean option C? Or am I misunderstanding "simple names
over multiples different names".
I greatly appreciate your input, btw. I'm just "mentally frozen" on
this. So any outside discourse really helps.
T.