Impossible to require "extension" shards

[vladfaust]

Let's imagine a shard which adds a new type of HTTP::Server, for example, HTTP::Superserver. This is a possible folder structure in a shard:

http-superserver
- src
- - http
- - - superserver.cr

It would be neat if a user could write

require "http/superserver"

in their code, which is currently impossible. Any ways to implement this?

[asterite]

A shard can reopen the HTTP module and add types, but expose these extensions in "http-superserver". Then you do:

require "http-superserver"

HTTP::Superserver

[vladfaust]

@asterite I definitely know that. I wonder if one could write require "http/superserver", which feels more natural.

It's an RFC, worths re-opening.

[asterite]

I don't understand what we win by changing the language and letting you write a "/" instead of a "-". There's no benefit at all.

[vladfaust]

@asterite

You don't find it's useful, but I do. The code is just a bit more beautiful. It's not fair to close issues just because you don't understand something.

If we can find a way to implement this without breaking the functionality, it will be awesome. Please be generous.

[asterite]

@vladfaust You must understand that we can't implement every feature someone proposes. If you do want to see this implemented, please explain how you would make it work. What does the compiler do when you write require "http/superserver"?

[Sija]

@vladfaust

• For the first, that's a wrong repo.
• For the second, title of this issue is not correct. Yes, you CAN require shards with class extensions.
• For the third, you haven't given any merit/use-cases to the feature you're proposing here. No-one requested this before either; problem your'e trying to solve doesn't exists (for anyone else except you, at least).

Please, think about the bigger scope of the project and not only your personal wishes.

[vladfaust]

@asterite, I do understand that:

we can't implement every feature someone proposes

The issue was not intended to be "do it for me, now" issue. You may notice that I'm on a fast-learning curve of Crystal, so I think that I'm able to help implementing this feature; but as mentioned below, I even missed the repository because I don't know how it's implemented at the moment.

@Sija, It looks like false consensus bias - you think that I know what you know. The truth is, I do not. The issue related to shards, because the compiler doesn't see the files if they're organized in a shard and required as in the first post. I thought that it is related to shards. My bad.

Also it's my bad to name the issue that way. But you know what? I can rename it. I can also add [RFC] badge. Just help me.

problem your'e trying to solve doesn't exists

Yes, unless you close an issue without a chance for other developers to see it :+1: Also I'm sure lots of developers think "Meh, it's not ideal, will use a workaround" or as we say in Russia: "No means no"; or they just think they can't change anything.

Both, The awaited behaviour from you is help and discussion. I'm the one of who really loves what you do, doesn't that deserve some respect?

Now, the examples:

• HTTP::Multiserver is another type of HTTP::Server, its place is near the standard one, it looks like it extends the basic functionality. It feels natural to require "http/multiserver", while "http-multiserver" feels like a separate project, which I intend to overcome;
• I have Tele project, which is a framework. There is a Tele::Broadcast module, it extends the framework's functionality. It feels more natural to require "tele/broadcast" rather than "tele-broadcast", it just fits right in, it feels like it always was here, like it belongs to "tele";
• Resque would consist of four separate modules, it would be weird to require "redis-client", then require "redis-worker". Doesn't it feel more natural to require "redis/client" and require "redis/worker"?

Sorry, my English isn't perfect, I can't express what I feel that ideally.

The basic idea is that, this encourages modularity and makes extension shards feel and look good. Please point me to a code where I can find what's can be changed.

[Sija]

All of your examples are valid reasons not to change the current behaviour. If you require "tele-broadcast" you immediately know from where the code comes from. It would be impossible if you could disguise code from your shard like part of stdlib. I'd be confused to say the least, since it's counter-intuitive behaviour. I'd expect to things be in their own namespace, let it be shard name, not always the path like you suggest.

[Papierkorb]

Being able to tell from only the require if it's something external or not seems like a good thing. Sure, being able require "http/fooserver" looks better on paper at first. But consider someone new coming to your project, who is now confused if "http/fooserver" was part of the stdlib or not.

Thus, the benefit ("looks nicer") doesn't outweigh the issues ("where does it come from?") it causes.

[ysbaddaden]

This behavior is frequent in Ruby, which requires it to hold a huge list of folders to search files for, at least one folder for each gem a project requires, then:

• any require has to search in all these folders;
• gems must bury their files under lib/<gem>/ to avoid clashes, leaving an almost empty lib directory.

Crystal chose to have a very limited list of folders to search: src, lib and /path/to/crystal/src; we won't push all lib/*/src folders into CRYSTAL_PATH. Furthermore we don't have to put our library code into src/<name>/ but can directly put it under src/ which is lovely to me :heart:

I'm sorry, but we won't implement this feature. An incompatible solution was chosen long ago, and we don't plan to change it.

[vladfaust]

@Sija, @Papierkorb, @ysbaddaden, I'm happy you've chosen to explain your decision. Thank you :+1:

However, how about allowing naming shards http/foorserver so don't need to change the behaviour of require?

We could mention in the specs that / naming is suitable only for shards which extend functionality... Or even we can say like "please, don't use extension shards to extend stdlibs, because it may confuse", but this will allow to make natural extensions for non-stlib shards.

Example shard's shard.yml:

name: http/fooserver

Example project's shard.yml:

dependencies:
  http/fooserver:
    github: vladfaust/http-fooserver # Is vladfaust/http/fooserver git name possible too?

Could this be implemented without interfering with incompatible solution was chosen long ago?

I know this could look a bit mad for you having such strong beliefs; but it's an Internet, where lots of viewing points are facing each other :smiley: