From noreply at rubyforge.org Thu May 3 15:11:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 3 May 2007 15:11:57 -0400 (EDT)
Subject: [Facets] [ facets-Bugs-10561 ] Dictionary#delete_if does not yield
iterated keys/values to block
Message-ID: <20070503191157.590245240BBE@rubyforge.org>
Bugs item #10561, was opened at 2007-05-03 15:11
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10561&group_id=804
Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Riley Lynch (rlynch)
Assigned to: Nobody (None)
Summary: Dictionary#delete_if does not yield iterated keys/values to block
Initial Comment:
Dictionary#delete_if reads:
def delete_if
order.clone.each { |k| delete k if yield }
self
end
The block passed to delete_if is being called without passing the iterated keys and values as arguments. This also breaks #reject and #reject! .
For compatibility with ::Hash#delete_if, it should pass both the key and the value:
def delete_if
order.clone.each { |k| delete k if yield(k,self[k]) }
self
end
----------------------------------------------------------------------
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10561&group_id=804
From transfire at gmail.com Tue May 8 13:07:14 2007
From: transfire at gmail.com (Trans)
Date: Tue, 08 May 2007 17:07:14 -0000
Subject: [Facets] Facets 2.0 Home Stretch
In-Reply-To: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
Message-ID: <1178644034.939372.320940@h2g2000hsg.googlegroups.com>
After more discussions and a survey, I've further refined the division
and naming of Facets subprojects. There will be, at least, the
following packages in the Facets repository:
CoreMethods
CoreModules
AdaptiveBase
AdaptiveCache
LiveCommand
LiveLibrary
LiveConcern
LiveNotes
LiveUnits
FileShell
At this point I am debating two things:
1) Whether to use "Base" instead of "Core" as the prefix for the
first two, ie. BaseMethods and BaseModules, or perhaps go back to
NanoMethods and MegaModules instead.
2) Whether to use "Open" instead of "Live" for the later packages
(including FileShell --eg. OpenShell) or some combination of the two
--"Live" for some and "Open" for others.
Please offer any opinions you have on this.
Once this is settled I'll finally be able to move forward. Praise the
Mother!
T.
From transfire at gmail.com Fri May 11 14:51:27 2007
From: transfire at gmail.com (Trans)
Date: Fri, 11 May 2007 18:51:27 -0000
Subject: [Facets] Facets 2.0 Home Stretch
In-Reply-To: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
Message-ID: <1178909487.543378.113120@e65g2000hsc.googlegroups.com>
Can you tell I'm running around in circles on this? I keep thinking
"okay, that's going to be it", but I never quite make it.
I think one of the fundamental distinctions that I've been missing is
that which lies between a common utility, and a more specialized tool.
For example, the Command base class is more specialized, while the
ANSICode module is more of a common utility. Ultimately I think it
would be nice to create a more cohesive tool that covers the full-
spectrum of requirements for console based apps. While it would make
sense to include all the components needed for this in the single
package, eg."Comrade", this would discourage others from using those
parts for their own equivalent utilities. In other words, by including
ANSICode in "Comrade", I've discouraged others from creating there own
command-line solutions that could re-utilize ANSICode. For this
reason, one can argue that something like ANSICode would be better off
as it's own package.
However packaging systems are generally poorly suited to small
reusable libs like this, which typically having but a single file. For
example, RubyGems package format and conventions for project layouts
are bulky relative to this need, and it is inefficient in it's effects
on Ruby's loadpath system. Also, it may be foolish to think an
ANSICode library would get much independent use anyway. If someone
needed it for another application they'd might just copy and paste it
into their own project --avoiding the dependency. That's the other
issue here. With so many small libraries one could easily have dozens
of such dependencies per application. While that upholds the common
mantra of "code reuse", it also comes at the practical costs of
dependency. This is the primary reason I came up with the idea of
GemBundles.
So I suppose I have to ask, what are we after? Is it to create
comprehensive solutions such as Comrade? Or simply to offer
essentially independent reusable components such as Command and
ANSICode? And if the later, is it acceptable to distribute so many
small packages, or must we accept packages groups even though it may
discourage reuse.
T.
From transfire at gmail.com Fri May 11 17:13:06 2007
From: transfire at gmail.com (Trans)
Date: Fri, 11 May 2007 21:13:06 -0000
Subject: [Facets] Unique Names vs Uniform Names Unique names provide maximum
independence. This allows for greater flexability in mixing
and matching tools to requirements. However they require
greater familiarity b/c various names must be remembered. In
addition,
this puts pressure on each package to only contain files that partake
in a more cohesive application. In this case,
parts of Facets might end-up in packages such as: kickstand
(additions to standard library) annotate (annotations)
taopoint (aop library) fileshell (file tools) freeload
(net-based require and module tools) comrade (command line
tools) magicdot (functor) The names are light and entertainting,
but their usage is not immediately evident just by the names. Of
course,
we can use names that are less entertaining and more to the point,
such as "cliutils" instead of "comrade". But this doesn't change much
as far as library usage. While it is easier to recognize for
what it is, it likewise looses brandability. Gogin further,
uniform names allow a large support library like Facets to be broken
down into categories. This makes them more convenient in that
they are easier to recall. Plus the files within these
catagories do not neccessiarily need to be as cohesive.
Facets categories could be: facets-core facets-meta
facets-file facets-math facets-cli facets-aop facets-ann
facets-mix facets-struct facets-open facets-misc Most of
these are fairly self-explanitory. It is interesting to note
that one of the categories is so small and cohesive that it
isn't really a category at all,
but rather has the feel of an independent library (namely 'ann').
Indeed, if we continued to break down these categories further,
each part would eventually fall out as it's own fully independent
library --for example: ansicode and multition. But that would
entail a huge set of libraries,
each of which seems too small to fully warrant the many packages. One
of the downsides of categorization is that pressure for
cohesion lies between the whole library,
not just the pacakged parts. Clearly it is expected that every part
of Facets will work well with the rest. In addition,
marketing/branding is hurt since there are no coined names to "sell".
We have only "Facets", which is good in itself,
but it's not well directed to specific problems. Someone in the
market for a CLI tool will not be as easily taken with a lib
called Facets-CLI,
since it suggests the "baggage" of the other Facets tools (even if it
is not necessarily the case). Unique vs Uniform
In-Reply-To: <1178909487.543378.113120@e65g2000hsc.googlegroups.com>
References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
<1178909487.543378.113120@e65g2000hsc.googlegroups.com>
Message-ID: <1178917986.843523.324660@u30g2000hsc.googlegroups.com>
Unique names provide maximum independence. This allows for greater
flexibility in mixing and matching tools to requirements. However they
require greater familiarity b/c various names must be remembered. In
addition, this puts pressure on each package to only contain files
that partake in a more cohesive application. In this case, parts of
Facets might end-up in packages such as:
kickstand (additions to standard library)
annotate (annotations)
taopoint (aop library)
fileshell (file tools)
freeload (net-based require and module tools)
comrade (command line tools)
magicdot (functor)
The names are light and entertaining, but their usage is not
immediately evident just by the names. Of course, we can use names
that are less entertaining and more to the point, such as "cliutils"
instead of "comrade". But this doesn't change much as far as library
usage. While easier to recognize for what it is, it likewise looses
brand-ability.
Taking the other approach, uniform names allow a large support library
like Facets to be broken down into categories. This makes them more
convenient in that they are easier to recall. Plus the files within
these categories do not necessarily need to be as cohesive. Facets
categories could be:
facets-core
facets-meta
facets-file
facets-math
facets-cli
facets-aop
facets-ann
facets-mix
facets-struct
facets-open
facets-misc
Most of these are fairly self-explanatory. It is interesting to note
that one of the categories is so small and cohesive that it isn't
really a category at all, but rather fits the criteria of an
independent library (namely 'ann'). Indeed, if we continued to break
down these categories further, each part would eventually fall out as
it's own fully independent library --for example: ansicode and
multition. But that would entail a huge set of libraries, each of
which seems too small to fully warrant the many packages (?)
One of the downsides of uniformity is that pressure for cohesion lies
between the whole library, not just the packaged parts. Clearly it is
expected that every part of Facets will work well with the rest. In
addition, marketing/branding is hurt since there are no coined names
to "sell". We have only "Facets", which is good in itself, but it's
not as well directed to specific problems. Someone in the market for a
CLI tool will not be as easily taken with a lib called Facets-CLI,
since it suggests the "baggage" of the other Facets tools (even if it
is not necessarily the case).
As you can see, I'm just trying to think out load here.
T.
From transfire at gmail.com Fri May 11 17:58:21 2007
From: transfire at gmail.com (Trans)
Date: Fri, 11 May 2007 21:58:21 -0000
Subject: [Facets] Unique Names vs. Uniform Names
Message-ID: <1178920701.501762.291610@o5g2000hsb.googlegroups.com>
Unique names provide maximum independence. This allows for greater
flexibility in mixing and matching tools to requirements. However they
require greater familiarity b/c various names must be remembered. In
addition, this puts pressure on each package to only contain files
that partake in a more cohesive application. In this case, parts of
Facets might end-up in packages such as:
kickstand (additions to standard library)
annotate (annotations)
taopoint (aop library)
fileshell (file tools)
freeload (net-based require and module tools)
comrade (command line tools)
magicdot (functor)
The names are light and entertaining, but their usage is not
immediately evident just by the names. Of course, we can use names
that are less entertaining and more to the point, such as "cliutils"
instead of "comrade". But this doesn't change much as far as library
usage. While easier to recognize for what it is, it likewise looses
brand-ability.
Taking the other approach, uniform names allow a large support library
like Facets to be broken down into categories. This makes them more
convenient in that they are easier to recall. Plus the files within
these categories do not necessarily need to be as cohesive. Facets
categories could be:
facets-core
facets-meta
facets-file
facets-math
facets-cli
facets-aop
facets-ann
facets-mix
facets-struct
facets-open
facets-misc
Most of these are fairly self-explanatory. It is interesting to note
that one of the categories is so small and cohesive that it isn't
really a category at all, but rather fits the criteria of an
independent library (namely 'ann'). Indeed, if we continued to break
down these categories further, each part would eventually fall out as
it's own fully independent library --for example: ansicode and
multition. But that would entail a huge set of libraries, each of
which seems too small to fully warrant the many packages (?)
One of the downsides of uniformity is that pressure for cohesion lies
between the whole library, not just the packaged parts. Clearly it is
expected that every part of Facets will work well with the rest. In
addition, marketing/branding is hurt since there are no coined names
to "sell". We have only "Facets", which is good in itself, but it's
not as well directed to specific problems. Someone in the market for a
CLI tool will not be as easily taken with a lib called Facets-CLI,
since it suggests the "baggage" of the other Facets tools (even if it
is not necessarily the case).
As you can see, I'm just trying to think out load here.
T.
From transfire at gmail.com Sat May 12 12:30:32 2007
From: transfire at gmail.com (Trans)
Date: Sat, 12 May 2007 16:30:32 -0000
Subject: [Facets] Unique Names vs. Uniform Names
In-Reply-To: <1178920701.501762.291610@o5g2000hsb.googlegroups.com>
References: <1178920701.501762.291610@o5g2000hsb.googlegroups.com>
Message-ID: <1178987432.741079.171640@h2g2000hsg.googlegroups.com>
If you hadn't yet noticed, the reason this issue is driving me so
crazy is b/c I don't like to do anything unless there is some good
rationality for doing so. So far there hasn't been much firm evidence
for pursuing one path over another in this quest of organizing Facets
into more manageable pieces. That's why I held an inductive poll. The
results of which were rather interesting in that they appear slightly
contradictory. While most indicated a preference toward categorical
names, when it came down to actual examples they leaned toward
creative names, with the single exception of names that were dead
simple --essentially too simple. Even so I still wanted some deductive
reasons for taking an approach, and I think I've finally made some
head way in that.
I believe I've ruled out the "categorical approach" I've previously
talked about. My reasoning is this: Categories actually do less for
the end-user. They seem nice at first, but mostly just help the
developer by breaking the whole library into more manageable pieces,
but those pieces aren't nearly as effective as encapsulating USECASE.
For example "facets-meta" holds meta-programming tools. That helps the
end-user very little since different meta-programming tools can be
worlds apart. The end-user is barely better off than knowing that a
single package "facets" has such tools. Likewise for "facets-
mix" (mixins), "facets-misc", and so forth. The situation gets a bit
better for "facets-cli", and much better for "facets-ann", but that's
because their divisions are narrower and more focused to a usecase, to
the point that they almost beg for their own independence. And so I've
concluded that functional categorization like this is less effective.
That leaves me with the choice between "solution organization" or "low-
level separation".
Solution organization means extracting closely related files and
making more cohesive packages out of them with their own brand names,
eg. Comrade. Anything that does not omit of this ability stays in a
single "general purpose" library. These new packages can still remain
part of a larger repository (eg. Facets), but they would nonetheless
be effectively independent. The only question that would remain if
this path is taken, is whether to use highly creative names, like
Comrade, or more subdued names, like BaseCommand.
Low-level separation means making any independently usable library a
separate package. After some thought on this, if I were to do it, I
think I'd use the prefix "fx_" for the many small packages. To give
you a taste of this approach, here is a list of about half of all the
packages that would come out of it:
fx_progressbar
fx_crypt
fx_inheritor
fx_snapshot
fx_basicobject
fx_dependency
fx_populate
fx_system
fx_behavior
fx_lazy
fx_promoteself
fx_timer
fx_binreadable
fx_metaphone
fx_mainmodule
fx_recorder
fx_typecast
fx_buildingblock
fx_reference
fx_uninheritable
fx_cachedelegator
fx_enumerable
fx_multiton
fx_reflection
fx_classmethods
fx_expirable
fx_rwdelegator
fx_cloneable
fx_functor
fx_nullclass
fx_coroutine
fx_hashbuilder
fx_overload
fx_semaphore
fx_association
fx_autoarray
fx_dictionary
fx_elementor
fx_heap
fx_linkedlist
fx_lrucache
fx_opencascade
fx_opencollection
fx_openobject
fx_orderedhash
fx_pool
fx_statichash
fx_syncobjects
fx_tuple
fx_version
fx_constants
fx_infinity
fx_interval
fx_ioredirect
The advantage of course is the ability to pick and choose just what
one wants/needs and nothing more. It's the ultimate in re-usability.
However, on the downside, it really makes the need for GemBundles an
absolutely pressing issue --I doubt few people like the idea of 20
independent gem dependencies for their project. Further, it requires a
little extra work to maintain such a large set of packages. And
perhaps worst of all, it also doesn't encourage much cohesion, i.e if
fx_infinity doesn't work with fx_interval, it would be difficult to
know, since the tests would be separated as well.
T.
From transfire at gmail.com Wed May 16 12:51:10 2007
From: transfire at gmail.com (Trans)
Date: Wed, 16 May 2007 16:51:10 -0000
Subject: [Facets] Unique Names vs. Uniform Names
In-Reply-To: <1178987432.741079.171640@h2g2000hsg.googlegroups.com>
References: <1178920701.501762.291610@o5g2000hsb.googlegroups.com>
<1178987432.741079.171640@h2g2000hsg.googlegroups.com>
Message-ID: <1179334270.831671.57470@o5g2000hsb.googlegroups.com>
Good news on the reorganization front. My new "solutions orientation"
has born some nice fruit. I hadn't clearly realized it before, but my
previous categorizations were discordant. On one had I was organizing
some libs by usage while on the other I was organizing by type of
programming construct. For example, command line tools vs. module
mixins. It's a bad match. So I have gone back and made sweeping
transformations in organization based solely on usage. With the
exception of minor discernments I still need to nail down, I am very
satisfied with the new sorting. These categories are so far:
General low-level / meta programming
Aspect Oriented Programming
Attributes and Annotations
Library Loading
Module Inclusion
Text Manipulation
Data Structures
Mathematics
DateTime/GPS
Filesystem / IO
Networking
Command Line / Console
I may combine Networking with Filesystem/IO b/c there are so few
networking related libs in Facets. I also may combine Library Loading
and Module Inclusion since there is some conceptual overlap between
them. But those minor details aside, like I said, I am very happy with
this. It makes a lot more sense as far as improving development, as
well as delivering focused solutions to end-users.
However, I am still left with an awful naming problem. I really don't
like anything I've come up with. When picking creative names, I really
only like three or four that I've considered (Comrade, Textile, Metal,
Taopoint) It becomes increasing burdensome to think of good creative
names that fit in well with others. Moreover, I'm not so sure I like
the idea of having to use all these names in require statements. Eg.
require 'comrade/command'
require 'taopoint/cut'
require 'textile/inflect'
But perhaps I should just accept this and keep working to find
acceptable names for the other 6 or 7 groups? The alternative of
hyphenated names doesn't seem any better (eg. facets-file). It can be
equally difficult to find a good concise descriptive word for them,
and the "facets" prefix conveys a lack of independence, which I don't
want. The benefit though is that separate require spaces aren't
important.
require 'facets/command'
require 'facets/cut'
require 'facets/inflect'
Is fine and obviously be a bit easier on the mind.
Because of this lingering dilemma I am considering a potential third
approach. In the spirit of Oniguruma, I was thinking about naming each
group by a related Japanese word. A few potential examples:
zokusei
raiburai
tekisuto
kouzou
hiduke
suugaku
And regardless of the independent names, the require statements could
still just use "facets/command", etc. Of course the downside here is
that those words have zero intrinsic meaning to non-Japanese speakers.
T.
From transfire at gmail.com Wed May 30 16:14:01 2007
From: transfire at gmail.com (Trans)
Date: Wed, 30 May 2007 20:14:01 -0000
Subject: [Facets] Facets 2.0 Home Stretch
In-Reply-To: <1178644034.939372.320940@h2g2000hsg.googlegroups.com>
References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
<1178644034.939372.320940@h2g2000hsg.googlegroups.com>
Message-ID: <1180556041.350595.54480@h2g2000hsg.googlegroups.com>
Hi,
I'm having trouble recognizing any solution-based categories to
organize these remaining libs. Any ideas? See any nameable patterns?
coroutine.rb
daemonize.rb
lazy.rb
nilasempty.rb
nilcomparable.rb
procbind.rb
rbsystem.rb
recorder.rb
reference.rb
rwdelegator.rb
semaphore.rb
snapshot.rb
todata.rb
typecast.rb
infinity.rb
interval.rb
quaternion.rb
random.rb
timer.rb
Thanks,
T.
From transfire at gmail.com Wed May 30 16:25:50 2007
From: transfire at gmail.com (Trans)
Date: Wed, 30 May 2007 20:25:50 -0000
Subject: [Facets] Facets 2.0 Home Stretch
In-Reply-To: <1178644034.939372.320940@h2g2000hsg.googlegroups.com>
References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com>
<1178644034.939372.320940@h2g2000hsg.googlegroups.com>
Message-ID: <1180556750.376588.104630@o5g2000hsb.googlegroups.com>
BTW, I had a good discussion with Peter Vanbroekhoven about the
organization of Facets 2.0. He had some excellent notions on the
matter which really helped me see this to a rational conclusion. It
took some herculean effort (basically my roll-playing with all
potential options) but the final result is proving to be well worth
all the hair-pulling effort.
The game really is a bit "best of both worlds". I divided up all of
Facets according to "solutions". For instance CLI-based libs are in
one package, AOP-related libs in another, and so on. This solution-
based approach had a huge positive effect on the layout. However, full-
on solution-based divisions were still lacking in one important
respect. Facets needed a central core which represented it's common
functionality. So I took a step back and put all _essential_ core
extensions in a separate package. Though they cover a variety of
solutions, these extensions are the ones you might half expect to
already be in Ruby proper. As such all of them are easily (though
optionally) loadable via a single require. I also made a secondary
package for extensions to Ruby's standard libs --since these aren't
loaded unless specifically required. So those are the two exceptions
to the pure solution-based divisions of Facets. As for names of each
of division, I was looking at highly _why-esque (ie. creative) names,
but I'm starting to lean toward simpler, more concise names; kind of
taking the Microsoft approach to marketing in that regard (eg.
Microsoft Surface). In any case the ultimate result will be packages
with names like "facets_core" and require statements like 'facets/
core/..'. With the potential for shortcuts (eg. require 'core') and
perhaps redirecting gem packages (eg. "gem install core" would install
facets_core as a dependency).
So that's the summary of what's coming down the line. Anyone who's
followed my dizzying ranting and raving on this matter these last
months can understand just how much I'm look forward to getting these
packages out the door :)
T.