Rename it to dry-types!

[marshall-lee]

Hello, @solnic!

I revisited your gem again and now it looks better to me. In fact, I find it somehow ideal because it gives maximum flexibility and the API is pretty good. I cannot believe because the first time I found dry-data very ugly.

So the last thing that bothers me is a name. What's wrong with it? Is it a reference to Haskell data keyword or what? If so then algebraic data types (structs and sum types in your terms) are not a whole picture. dry-data works not only with them but with primitive types too. If it's not a reference to data keyword then what it is? It looks that dry-data is not about data but types. Do you agree with me or maybe I'm missing something?

[solnic]

I called it like that because I use it to work with data. It is also a nice
namespace tbh. Let's discuss this with a broader audience. I don't have a
strong preference.

And thanks for feedback! I understand why it looked ugly to you. It's been
shaping up nicely though in the recent months. The usage in many places
influences its API and so far it was very useful already and it's just the
beginning :)

ps. Me playing with Haskell definitely influenced me in some way but it
wasn't the only reason to call it dry-data ;)
On Thu, 21 Jan 2016 at 18:24, Vladimir Kochnev notifications@github.com
wrote:

Hello, @solnic https://github.com/solnic!

I revisited your gem again and now it looks better to me. In fact, I find
it somehow ideal because it gives maximum flexibility and the API is
pretty good. I cannot believe because the first time I found dry-data
very ugly.

So the last thing that bothers me is a name. What's wrong with it? Is it a
reference to Haskell data keyword or what? If so then algebraic data
types (structs and sum types in your terms) are not a whole picture.
dry-data works not only with them but with primitive types too. If it's
not a reference to data keyword then what it is? It looks that dry-data
is not about data but types. Do you agree with me or maybe I'm
missing something?

—
Reply to this email directly or view it on GitHub
#21.

[solnic]

I've been thinking about this and currently leaning towards what you suggested. dry-types would better explain what it is, after all it's a library for type definitions.

[timriley]

dry-types makes a lot of sense to me. I see it as a way of adding some sort of "type safety" to my apps already.

[mrbongiolo]

The project name dry-types seems ok.
But as someone said, what about the namespaces? Dry::Types::Type would be a bit strange.
In the end of the day dry-data isn't that wrong also...

[pascalbetz]

I'd go with dry-types even with the consequences of having

module Dry
  module Types
    module Type
      ...
      ...
    end
  end
end

The name of the library should reflect it's usage. Or be something creative/abstract. But now it's misleading. Well of course only until you read the README:-)

Type is like Category, Group, ... Perhaps it's to generic?

• `dry-type_system``
• dry-ts
• `dry-nature``
• dry-variety
• ah well... not really better.

[solnic]

@mrbongiolo public interface for defining types will not expose this class to you (not done yet) so I guess it's not such a big deal after all

@pascalbetz I agree, I've thought about this and I like the idea of renaming to dry-types :)

Thanks for feedback!

[mrbongiolo]

why not: dry-types-n-coerce--search-n-destroy??? But now seriously, +1 for dry-types.

BTW, we would still declare an app module Types to be used with it? Or is it also changing?

[marshall-lee]

@mrbongiolo

BTW, we would still declare an app module Types to be used with it? Or is it also changing?

Well, if you're brave enough, you could try to setup types globally, passing the Object namespace instead of Types :)

If talking seriously, I don't see any reason to change this. And even more, I wish there is a way to terraform multiple type spaces not just the global one. Why it's good? For now, dry-data is designed more for the app developer, not for gem developer who may also want to use dry-data. Of course, in many cases it's better to design a library in the way where types are passed as a dependencies. But it's not always good. I cannot come up with right example for now so it's a thing to rethink in the future.

[solnic]

@marshall-lee you can define types on any namespace you want via Dry::Data.define_constants(some_namespace, list_of_type_ids) API but it should be more first-class, I gotta say, it feels too rough at the moment :)

FWIW I want dry-data (dry-types!) to be easily usable in libraries too, in fact I already started using it in rom-sql where custom SQL-types are being defined on top of the built-in ones. So this will be one of the use cases for this gem and I definitely want to make sure it has nice APIs to support it.

[george-carlin]

Can I suggest recreating the https://github.com/dry-rb/dry-data repo so that it redirects to the new URL, or contains a simple README noting that the repo has been renamed and moved?

There are a lot of links around (including on @solnic's own blog ;) ) that still point to "dry-data" and now those links 404; it's not clear to a newcomer what happened to that repo (i.e. that it was just renamed and not e.g. deleted altogether or broken up into smaller gems)

[timriley]

Given that a google search for dry-data returns this dry-types repo as the first result, I don't think this is really a problem.

I'm pretty sure GitHub automatically handle redirects for some period of time after a rename, which is probably why this happened.

[solnic]

I'll update my blog posts with some info about the rename.

On 19 October 2016 at 04:47:09, Tim Riley (notifications@github.com) wrote:

Given that a google search for dry-data returns this dry-types repo as the
first result, I don't think this is really a problem.

I'm pretty sure GitHub automatically handle redirects for some period of
time after a rename, which is probably why this happened.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#21 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAEKrHCwvGZxf5voIQcTGhBScEd-OQ4ks5q1YStgaJpZM4HJsYr
.