Stu Halloway,
I used the reasoning from your thread to convince Stuart Sierra to
switch argument order between str-utils2 & str-utils3:
http://groups.google.com/group/clojure-dev/browse_thread/thread/7ab69b1d43012917
Args go last.
Sean
On May 27, 3:16 pm, Stuart Halloway wrote:
> > You also me
On Thu, May 27, 2010 at 19:28, Sean Devlin wrote:
> Oh, and following the tradition of clojure.java.io, you'll probably
> want to name it clojure.java.string, since it relies heavily on
> interop.
If bits of Java poke through the public interface, yes. This is
certainly the case for clojure.java.
> You also mention making the string argument first in some of these
> fns. I believe Will Smith's catch phrase says it best: "Aw hell
> no". String fns are like any other seq fn, and they need to be
> partial'ed, comp'ed and chained appropriately. I can't even begin to
> count the number of po
Oh, and following the tradition of clojure.java.io, you'll probably
want to name it clojure.java.string, since it relies heavily on
interop.
Sean
On May 27, 11:55 am, Stuart Halloway
wrote:
> Thanks to everyone for feedback on this thread. I have updated the ticket to
> include a list of change
Thanks to everyone for feedback on this thread. I have updated the ticket to
include a list of changes and open questions, and will be working on a patch
for review.
Stu
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send em
Hi Brian,
(1) Other than split-lines, what other non-promoted fns do you think are common
enough to deserver promotion?
(2) upper-case and lower-case are there for symmetry with capitalize. It's a
judgment call, but one I am still comfortable with.
(3) nil-handling is on the list of things to
Hi,
On 27 Mai, 15:35, Michael Gardner wrote:
> On May 27, 2010, at 2:45 AM, Stefan Kamphausen wrote:
>
> > Hi,
>
> > On May 26, 11:00 pm, Stuart Halloway
> > wrote:
> >> The people have spoken! The trims have it!
>
> > sorry, I'm a little late. However, to me it is not clear what the
> > trim f
On May 27, 2010, at 2:45 AM, Stefan Kamphausen wrote:
> Hi,
>
> On May 26, 11:00 pm, Stuart Halloway
> wrote:
>> The people have spoken! The trims have it!
>
> sorry, I'm a little late. However, to me it is not clear what the
> trim functions shall do. If they become a replacement for chomp t
On May 26, 8:12 pm, Mohammad Khan wrote:
> personally, I like strip or trim [rather] than chomp/chop.
+1 from a mostly-Python programmer :-)
On May 26, 8:15 pm, Mark Engelberg wrote:
> If you're developing a trio, like ltrim, trim, rtrim, wouldn't it be
> better to call them triml, trim, trimr
> Stefan Kamphausen writes:
> sorry, I'm a little late. However, to me it is not clear what the
> trim functions shall do. If they become a replacement for chomp they
> are clearly misnamed. In many applications and languages (like Excel,
> several SQL variants, oh, and Java, ...) "trim" means s
On 26 May 2010 23:09, Eric Schulte wrote:
> Mark Engelberg writes:
>
>> If you're developing a trio, like ltrim, trim, rtrim, wouldn't it be
>> better to call them triml, trim, trimr so that they show up next to
>> each other in the alphabetized documentation?
>
> +1 for modifiers at the end
>
>
First of all, good idea to have a dedicated string library in core. we
use String manipulations often enough to make that worthwhile.
The goal should be on making operations easy and efficient. Mostly a
string is just a value like 42, 1.25 or 27-MAY-2010, calling for
simple "arithemetic" function
Hi,
On May 26, 11:00 pm, Stuart Halloway
wrote:
> The people have spoken! The trims have it!
sorry, I'm a little late. However, to me it is not clear what the
trim functions shall do. If they become a replacement for chomp they
are clearly misnamed. In many applications and languages (like Ex
Mark Engelberg writes:
> If you're developing a trio, like ltrim, trim, rtrim, wouldn't it be
> better to call them triml, trim, trimr so that they show up next to
> each other in the alphabetized documentation?
+1 for modifiers at the end
Let's not forget those of us who search for functions u
On May 26, 12:42 pm, Sean Devlin wrote:
> I'd like to see a specific proposal for replace & replace-first.
> Stuart Sierra put a lot of effort into getting those fns the way they
> are in contrib, and we should be careful to not undo any lessons
> learned in the process.
Yes, originally replace a
The people have spoken! The trims have it!
Stu
I've done Perl coding and I still mix up chomp and chop. The meaning
of trim, ltrim, and rtrim is immediately clear to me.
trim, ltrim, and rtrim could take an optional argument for characters
to strip:
(rtrim foo) ;; strip trailing whitespace
I've done Perl coding and I still mix up chomp and chop. The meaning
of trim, ltrim, and rtrim is immediately clear to me.
trim, ltrim, and rtrim could take an optional argument for characters
to strip:
(rtrim foo) ;; strip trailing whitespace
(rtrim foo "\r\n") ;; equivalent to chomp
If
> personally, I like strip or trim than chomp/chop.
>
+1
Seeing how Clojure dropped/changed many classic Lisp monikers, there
is no reason to use comp/chop which may be familiar to somebody with
Perl/Python but confusing to others.
--
You received this message because you are subscribed to the
This thread has potential to be the longest thread of clojure mailing list!
personally, I like strip or trim than chomp/chop.
On Wed, May 26, 2010 at 2:08 PM, Fogus wrote:
> > "chomp" has a clear meaning to anyone who's touched Perl/Ruby/shell-
> > scripting.
>
> Believe me I can sympathize wit
On Wed, 2010-05-26 at 13:57 -0400, Mike Meyer wrote:
> On Wed, 26 May 2010 19:47:25 +0200
> Peter Schuller wrote:
>
> > > chomp => rtrim
> > > (rtrim "foo\n") => "foo" is much more clear to me, plus it leaves the
> > > door open for trim and ltrim functions should the need arise.
> >
> > I lik
If you're developing a trio, like ltrim, trim, rtrim, wouldn't it be
better to call them triml, trim, trimr so that they show up next to
each other in the alphabetized documentation?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this grou
> "chomp" has a clear meaning to anyone who's touched Perl/Ruby/shell-
> scripting.
Believe me I can sympathize with this, but just because they are well-
known to some doesn't mean that they are good names. On that note,
just because rtrim and less make sense to me... you know the
rest. :-)
:f
On May 26, 10:29 am, Fogus wrote:
> I have mentioned my gripes in the IRC, but for public view I would
> love better names for chomp and chop. In isolation those names are
> meaningless, so I suggest:
Almost every name in a programming language is meaningless in
isolation. But we don't work in
> Personally, I like the lstrip/strip/rstrip, but that's just because
> I'm used to them.
strip is fine too IMO; I'm neutral between *strip and *trim.
--
/ Peter Schuller
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send e
On Wed, 26 May 2010 19:47:25 +0200
Peter Schuller wrote:
> > chomp => rtrim
> > (rtrim "foo\n") => "foo" is much more clear to me, plus it leaves the
> > door open for trim and ltrim functions should the need arise.
>
> I like this. And in general I often fine the entire trio useful, and
> adopt
On May 26, 8:16 am, Stuart Halloway wrote:
> If you are a user of clojure.contrib.string, please take a look at the
> proposed promotion to clojure [1]. Feedback welcome! It is my hope
> that this promotion has enough "batteries included" that many libs can
> end their dependency on contrib
> chomp => rtrim
> (rtrim "foo\n") => "foo" is much more clear to me, plus it leaves the
> door open for trim and ltrim functions should the need arise.
I like this. And in general I often fine the entire trio useful, and
adopting the ltrim/trim/rtrim naming makes it nice and tidy.
While I recogn
> Changed our mind. It helps keep the people with prerelease books
> busy. ;-)
Oh great! I'm going to have to cancel my appearance on "The View"
because of this.
I have mentioned my gripes in the IRC, but for public view I would
love better names for chomp and chop. In isolation those names a
Stu Halloway,
Changes like this are a nuisance as a documentation guy >:| It makes
Beta seem further away, but it's a tough call and someone has to make
it. Such is life on the edge.
As far as technical feedback goes, it seems like a VERY useful list to
promote to core. There are a few things I
Definitely! It will be clojure.string. Ticket updated to reflect this.
Are these going to be in their own namespace (clojure.string), or in
core? I hope the former, because many of these names (replace,
reverse, join, split) are too valuable to be dedicated only to
strings.
--
You received t
Are these going to be in their own namespace (clojure.string), or in
core? I hope the former, because many of these names (replace,
reverse, join, split) are too valuable to be dedicated only to
strings.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group
Stu,
What happened to *not* promoting string?
Changed our mind. It helps keep the people with prerelease books
busy. ;-) Seriously: I did an audit of several third-party libraries,
and concluded that for some libs, the presence of these string
functions in core could be the make-or-break d
Stu,
What happened to *not* promoting string?
http://groups.google.com/group/clojure-dev/browse_thread/thread/e294cd444227
Also, is there an actual patch/diff to review? I didn't see one in
Assembla.
Sean
On May 26, 11:16 am, Stuart Halloway
wrote:
> If you are a user of clojure.contrib.s
If you are a user of clojure.contrib.string, please take a look at the
proposed promotion to clojure [1]. Feedback welcome! It is my hope
that this promotion has enough "batteries included" that many libs can
end their dependency on contrib for string functions.
Cheers,
Stu
[1] https://www
34 matches
Mail list logo
