In a way I like the idea of sub-classing because it's cleaner and more
consistent with how most of MooTools is designed. Although there are
several places where the pattern is to extend properties or hashes
(Element, Event, $).
Is the sub-class the same as the URI scheme or a new classification
though? For example: http:, https:, file:, webcal:, mms:, ldap:,
news:, svn:, git: are really different schemes with possibly different
extensions and meaning. Some are a superset or subset of these
schemes. Some share protocol. Some follow different schemes but would
still be considered a "locator" and hence a URL. So URI.URL would
still need to be able to be extended with various schemes.
If we introduce classifications such as "URL" and "Email" there could
also be the issue of what happens if a scheme belongs to both. I don't
really have an example so it could be an edge case. Possibly the im
scheme and tel/skype style phone URIs.
About validation... In my variant I utilized the regexps for a pattern
like this: Uri.validate('any known uri scheme'); OR Uri.validate.mailto
('mailto:m...@email?subject=test');
MooTools doesn't really use throws or try-catches anywhere and IMO
it's with good reason. You could also do URI.URL.validate('any known
URL scheme');
However, Uri.validate.mailto() would still only validate a mailto: URI
and not an actual e-mail per say. Even Uri.validate.mailto('mailto:' +
email); would still consider 'm...@email?subject=test' valid. But this
is a particular edge case with e-mails. Either way, I don't think e-
mail validation belongs in the URI class since the URI is really a
superset scheme of e-mail addresses.
On Mar 11, 5:08 am, Guillermo Rauch <[email protected]> wrote:
> As you said, if let's say concatenation works flawlessly with a Class as it
> does with String, I don't see any other reason to subclass String.As far as
> the class design goes, I would like an approach like:
>
> URI = Base, abstract class.
> URI.URL = extends URI for the URL scheme
> URI.Email = extends URI for the email scheme
>
> and user can also extend it for the scheme he deals with.
>
> Since the API changes for each scheme (the name of the parts that you can
> get), I don't see the point of having all the logic into URI. It's not like
> the method get('username') will work for all schemes, hence why it's a good
> idea to inherit from URI.
>
> Also, from FormValidator we could do something like:
>
> try {
> new Email(email_value);} catch(e){
>
> this.error('wrong email');
>
> }
>
> In any case, we can also use URI as a factory to create instances for a
> scheme
>
> URI.create('http://', 'url');
> URI.create('http://', 'email');
>
> On Wed, Mar 11, 2009 at 1:59 AM, Thomas Aylott <[email protected]
>
>
>
> > wrote:
>
> > The biggest issue is consistency.
> > Nothing else in MooTools subclasses String.
> > This is More and not Core, so the rules aren't as hard and fast.
> > But I don't think I want to recommend that people subclass string.
>
> > It all boils down to who is going to write all the specs and maintain this
> > thing into the future.
> > I'm not going to, so I don't get a real vote.
>
> > All I really need it to do is handle the stuff I want. I'd rather not have
> > to use toString() on it if I don't have to.
> > If I don't have to do that with a normal Class, then what's the point of it
> > being a string subclass?
>
> > —Thomas Aylott / subtleGradient
>
> > On Mar 10, 2009, at 11:12 PM, Sebastian Markbåge wrote:
>
> > About concatenation. I just added a test for that. new Uri('...') +
> >> 'string' and 'string' + new Uri('...') both work as expected. So
> >> assuming it is two strings being concatenated it will work anyway. You
> >> can also use it to test a regexp: (/^...$/).test(new Uri('...'))
>
> >> So I guess we're down to whether or not the String-manipulation
> >> methods such as substr, replace etc. are needed. And that boils down
> >> to whether or not a URI is a String?
>
> --
> Guillermo Rauchhttp://devthought.com
