This is awesome…welcome to the contributing community members!
Its cool to announce libraries here (until we get so very overwhelmed
with new code announcements that we need to do something about it 
One quick recommendation is to use the index method as an alias for
value_of on the VCard object…that way you could do this:
VCDATA =<<END
BEGIN:VCARD
VERSION:3.0
N:Kilmer;Rich;;;
FN:Kilmer Rich
EMAIL;type=HOME:rich@monotheos.com
EMAIL;type=WORK;type=pref:rich@infoether.com
END:VCARD
END
card = Rfc2425::VCard.new(VCDATA)
puts card[“email”] #=> rich@infoether.com
and possibly accept symbols in addition to strings:
puts card[:email] #=> rich@infoether.com
and perhaps enable a second (optional) param for the type:
puts card[:email, :home] #=> rich@monotheos.com
To define such as method:
class VCard
def (fieldname, ftype=nil)
…
end
end
Anyway…just ideas…and thanks for the library,
rich
···
On Saturday, March 15, 2003, at 01:19 PM, Sam Roberts wrote:
http://raa.ruby-lang.org/list.rhtml?name=vcard
An implementation of the MIME Content-Type for Directory Information
(RFC 2425), and profiles of this format. The basic RFC 2425 format is
implemented by the DirectoryInfo class. Currently the only supported
profile is vCard (RFC 2426), implemented by the Vcard class.
This is my first Ruby module, and I would love to have feedback on
useability, Ruby-ishness, API suggestions, bug reports, anything,
really!
Sam
Btw, is it OK to announce things to ruby-talk? Is it just considered
noise?
Quoteing rich@infoether.com, on Sun, Mar 16, 2003 at 04:15:57AM +0900:
One quick recommendation is to use the index method as an alias for
value_of on the VCard object…that way you could do this:
VCDATA =<<END
BEGIN:VCARD
VERSION:3.0
N:Kilmer;Rich;;;
FN:Kilmer Rich
EMAIL;type=HOME:rich@monotheos.com
EMAIL;type=WORK;type=pref:rich@infoether.com
END:VCARD
END
card = Rfc2425::VCard.new(VCDATA)
puts card[“email”] #=> rich@infoether.com
I thought about it, but didn’t because I ran into the “which one do I
return, there can be multiple fields with that name” problem.
I just looked at RFC2426 in more detail, though, and it appears that
type=pref is allowed for a lot of things that can have multiple
occurences.
and possibly accept symbols in addition to strings:
puts card[:email] #=> rich@infoether.com
and perhaps enable a second (optional) param for the type:
puts card[:email, :home] #=> rich@monotheos.com
class VCard
def (fieldname, ftype=nil)
…
end
end
And if there are multiple matches, you’ll always get the first, unless
one of them is pref?(), ok?
Cheers,
Sam
Well, you could always return an array.
puts card[:email] #=> [ rich@infoether.com ]
···
On Sun, Mar 16, 2003 at 05:05:34AM +0900, Sam Roberts wrote:
Quoteing rich@infoether.com, on Sun, Mar 16, 2003 at 04:15:57AM +0900:
One quick recommendation is to use the index method as an alias for
value_of on the VCard object…that way you could do this:
VCDATA =<<END
BEGIN:VCARD
VERSION:3.0
N:Kilmer;Rich;;;
FN:Kilmer Rich
EMAIL;type=HOME:rich@monotheos.com
EMAIL;type=WORK;type=pref:rich@infoether.com
END:VCARD
END
card = Rfc2425::VCard.new(VCDATA)
puts card[“email”] #=> rich@infoether.com
I thought about it, but didn’t because I ran into the “which one do I
return, there can be multiple fields with that name” problem.
I just looked at RFC2426 in more detail, though, and it appears that
type=pref is allowed for a lot of things that can have multiple
occurences.
–
Alan Chen
Digikata Computing
http://digikata.com
Ok, I implemented it.
I don’t want to upload it to RAA right now, because I think asking them
to move 3 files from incoming to contrib in a week is a little much, and
I’m working on encoding, hooks into the OS X Address Book, and a script
to do Address Book lookups from within mutt right now, and thats all
stuff I want to release in the next few days.
I’ll send 0.2 to anybody who’s interested. Only change is the addition
of the functions described below by Rich.
I didn’t make things work with symbols yet, because I think its such a
good idea that I’m going to make using symbols rather than strings for
hash indexing and lookups pervasive, I think it will be much more
efficient, particularly because right now I’m .downcase()ing my strings
all over the place because comparisons are suppposed to be
case-insensitive.
Thanks a lot for the feedback.
Cheers,
Sam
Quoteing sroberts@uniserve.com, on Sun, Mar 16, 2003 at 05:05:34AM +0900:
···
Quoteing rich@infoether.com, on Sun, Mar 16, 2003 at 04:15:57AM +0900:
One quick recommendation is to use the index method as an alias for
value_of on the VCard object…that way you could do this:
VCDATA =<<END
BEGIN:VCARD
VERSION:3.0
N:Kilmer;Rich;;;
FN:Kilmer Rich
EMAIL;type=HOME:rich@monotheos.com
EMAIL;type=WORK;type=pref:rich@infoether.com
END:VCARD
END
card = Rfc2425::VCard.new(VCDATA)
puts card[“email”] #=> rich@infoether.com
I thought about it, but didn’t because I ran into the “which one do I
return, there can be multiple fields with that name” problem.
I just looked at RFC2426 in more detail, though, and it appears that
type=pref is allowed for a lot of things that can have multiple
occurences.
and possibly accept symbols in addition to strings:
puts card[:email] #=> rich@infoether.com
and perhaps enable a second (optional) param for the type:
puts card[:email, :home] #=> rich@monotheos.com
class VCard
def (fieldname, ftype=nil)
…
end
end
And if there are multiple matches, you’ll always get the first, unless
one of them is pref?(), ok?
Cheers,
Sam
I think the index method returning the preferred field (if pref is
specified) or the first (of many) is acceptable. I would not use the
index method if I wanted a full enumeration (and you provide methods
for that) but for quick access. If you had two work email addresses
(and none were preferred) I think as long as I get one, I would be
happy.
if vcard[:email]
…send email
end
I would not want to have to always check for an Array vs. a String
thought…that would make code kind of messy.
-rich
···
On Saturday, March 15, 2003, at 03:18 PM, Alan Chen wrote:
Well, you could always return an array.
puts card[:email] #=> [ rich@infoether.com ]
On Sun, Mar 16, 2003 at 05:05:34AM +0900, Sam Roberts wrote:
Quoteing rich@infoether.com, on Sun, Mar 16, 2003 at 04:15:57AM +0900:
One quick recommendation is to use the index method as an alias
for
value_of on the VCard object…that way you could do this:
VCDATA =<<END
BEGIN:VCARD
VERSION:3.0
N:Kilmer;Rich;;;
FN:Kilmer Rich
EMAIL;type=HOME:rich@monotheos.com
EMAIL;type=WORK;type=pref:rich@infoether.com
END:VCARD
END
card = Rfc2425::VCard.new(VCDATA)
puts card[“email”] #=> rich@infoether.com
I thought about it, but didn’t because I ran into the “which one do I
return, there can be multiple fields with that name” problem.
I just looked at RFC2426 in more detail, though, and it appears that
type=pref is allowed for a lot of things that can have multiple
occurences.
–
Alan Chen
Digikata Computing
http://digikata.com
I used to have APIs that returned an array, a string, or nil (if there
were multiple, 1, or no values). I thought it was cool.
But… it turns out every time you call something you basically need a
switch to figure out what to do with it!
I also noticed that Enumrable.find_all() always returns an array, its
just sometimes it has a size of zero.
So, I’ve been drifting towards that.
Currently, the _all() APIs return an array, or nil, so if the return
value is true, then there is guaranteed to be at least one member, but
I’m starting to feel there’s a mismatch between this way, and the Ruby
Way, so I might just always return an array for the _all() functions.
I’m still thinking about it.
What to other people do? I don’t have experience with enough APIs to
know.
Cheers,
Sam
Quoteing rich@infoether.com, on Sun, Mar 16, 2003 at 05:34:48AM +0900:
···
I think the index method returning the preferred field (if pref is
specified) or the first (of many) is acceptable. I would not use the
index method if I wanted a full enumeration (and you provide methods
for that) but for quick access. If you had two work email addresses
(and none were preferred) I think as long as I get one, I would be
happy.
if vcard[:email]
…send email
end
I would not want to have to always check for an Array vs. a String
thought…that would make code kind of messy.
-rich
On Saturday, March 15, 2003, at 03:18 PM, Alan Chen wrote:
Well, you could always return an array.
puts card[:email] #=> [ rich@infoether.com ]
FWIW, in the DBI library which I have been using quite a lot recently:
dbh.select_one returns nil or a row
dbh.select_all returns an array of rows, or if no rows were found
can be convenient because you can do ‘each’ on the result without having
to test for nil first.
Regards,
Brian.
···
On Sun, Mar 16, 2003 at 07:21:26AM +0900, Sam Roberts wrote:
I also noticed that Enumrable.find_all() always returns an array, its
just sometimes it has a size of zero.
So, I’ve been drifting towards that.
Currently, the _all() APIs return an array, or nil, so if the return
value is true, then there is guaranteed to be at least one member, but
I’m starting to feel there’s a mismatch between this way, and the Ruby
Way, so I might just always return an array for the _all() functions.
I’m still thinking about it.
What to other people do? I don’t have experience with enough APIs to
know.
In RMagick, the Image.read method reads an file that can contain 1 or
more frames (an animated GIF, for instance). The method always returns
an array of image objects. If no error occurs the array contains 1 or more
elements.
If you know you’re going to be reading a file containing a single frame, you can
code
img = Magick::Image.read(‘mom.jpg’).first
This is inelegant but better, imho, than having 2 methods, one that
returns a single image and one that returns an array of images.
···
On Sun, 16 Mar 2003 07:21:26 +0900, Sam Roberts wrote:
I used to have APIs that returned an array, a string, or nil (if there
were multiple, 1, or no values). I thought it was cool.
But… it turns out every time you call something you basically need a
switch to figure out what to do with it!
I also noticed that Enumrable.find_all() always returns an array, its just
sometimes it has a size of zero.
So, I’ve been drifting towards that.
Currently, the _all() APIs return an array, or nil, so if the return value
is true, then there is guaranteed to be at least one member, but I’m
starting to feel there’s a mismatch between this way, and the Ruby Way, so
I might just always return an array for the _all() functions. I’m still
thinking about it.
What to other people do? I don’t have experience with enough APIs to know.
Cheers,
Sam