Allow forcing the name of the class

Question

Allow forcing the name of the class

Closed this issue 8 years ago · 15 comments

Meteor supports CoffeeScript. Its build system provides a way to share symbols between multiple files by attaching the symbol to a special share symbol which can then be accessed in other files. The issue is that codo uses this share prefix when displaying the name of the class, but this is just an internal feature which should not be exposed to developers. It would be great if I could force the name of the class (@name ClassName) so that it is everyone displayed without the share prefix.

Example of code:

This is how it is rendered now: https://peerlibrary.github.io/meteor-blaze-common-component/#https://peerlibrary.github.io/meteor-blaze-common-component/class/share/CommonComponentBase.html

Answer 1 · 2016-08-05T16:31:53.000Z

I don't see why it's a better way of showing without share. It is an actual name of the class. And it's something that you also probably want to keep in mind when you read about Meteor app. Isn't it so?

Answer 2 · 2016-08-05T18:12:12.000Z

This class could be seen as a private class. So it is not really something a Meteor developer would care how it is named, because they cannot access it anyway. But it is important for them to see which methods do they get from that class. And so I would just like a bit nicer name, this is all.

Answer 3 · 2016-08-05T21:32:59.000Z

I'm sorry, I'm not into meteor. But what you state doesn't make any sense to me. A Private class is by definition unaccessible. And if it is accessible - you do case about it's signature and name. I can't imagine something between. Anyway, in the referenced link you pointed out that the problem is in the Meteor inability to use import. Maybe we could just wait for the fix and live with share? I don't think having @name to workaround a problem in a particular framework is a good idea. It will not make it into master, I'm sorry.

Answer 4 · 2016-08-05T21:34:30.000Z

Private class is not accessible, but you still want it documented, no?

Answer 5 · 2016-08-05T21:35:28.000Z

Yes. But then everything is important. The name, the signature, everything. That prefix there plays a role. Omitting it would hide the role from the documentation. Changing the name of a class in tech doc is the last thing you want to do. It doesn't make any sense.

Answer 6 · 2016-08-05T21:37:17.000Z

Again, you gave it share prefix right? However let me suggest you a workaround:

class Foo
  # ...

share.Foo = Foo

Even if I didn't have to use Codo I'd still go this way by the way. If you aren't using the namespacing as a namespacing - keep it separately. You making a need for ugly hack even worse with class share .Foo. Just opinion.

Answer 7 · 2016-08-05T21:42:22.000Z

Yes, the issue is that by doing that, and in the other file:

Foo = share.Foo

class Bar extends Foo

Codo does not link the Bar as child class of Foo. :-(

Answer 8 · 2016-08-05T21:43:13.000Z

That's already interesting. Can you post an example of such problem somewhere? It should.

Answer 9 · 2016-08-05T21:44:02.000Z

I need source files that generate improper result. Preferably as a test PR 😈 . But just files will do ;)

Answer 10 · 2016-08-05T21:57:54.000Z

OK, this one was my mistake. It works if I do it on both sides for Codo, but it does not work for Meteor (there is one bug). This is why then it didn't work for me because I was doing some extra workarounds.

So, you are right. No need for this. This is just a bug in Meteor and there are enough ways to do it with Codo.

Sorry for noise.

Answer 11 · 2016-08-05T22:04:26.000Z

Because of this bug: meteor/meteor#7558

Meteor is post-processing CoffeeScript list of local variables to remove some of them (the ones I want exported). And because in comments I use backticks (for Codo to render), Meteor thinks I am using ES2016 and additionally post-process that list with Babel, which rewraps it, which makes Meteor not correctly remove local variables so variables are not exported. So it does not work for Meteor in the sense that I cannot export the class Bar anymore after I do the above trick, because only the first defined variable can be exported with this bug, and I use it for Foo = share.Foo.

So, don't worry. Just bad strange interaction between multiple things.

Answer 12 · 2016-08-05T22:05:06.000Z

@mitar ah, I see... Well, ok. If there's anything else - will be here :)

Answer 13 · 2016-08-05T22:06:40.000Z

Thanks! :-) I really appreciate all your help and time.

Answer 14 · 2016-08-05T22:08:19.000Z

BTW, it is really easy to use GitHub + Travis CI to automatically compile and publish Codo documentation: https://github.com/peerlibrary/meteor-blaze-common-component/blob/master/.documentation.sh

So there is no need for CoffeeDoc.info anymore.

Answer 15 · 2016-08-05T22:09:16.000Z

Since the original author of Codo passed away... I don't have access to it. But I will check that and update when I have a time, thanks.