Re: __doc__ for functions, classes, objects etc.

In the example implementation that I created, toString() was used exclusively because it "worked" in the single environment that I tested in and gave me the minimum that I needed to produce a working proof of concept - not to show any kind of support for a better specified Function.prototype.toS

Re: __doc__ for functions, classes, objects etc.

What about a simple property? readFile.documentation = { name: 'readFile', arguments: [ { name: 'path', type: 'string' }, { name: 'encoding', type: 'string', optionnal: true }, {

Re: __doc__ for functions, classes, objects etc.

On 5 September 2011 16:12, Dmitry Soshnikov wrote: > ** > On 05.09.2011 13:26, Andreas Rossberg wrote: > > I am indifferent about the general idea of a doc interface, > > > Then I don't think incorrect judging about the concept of an "abstraction" > is a good topic in this thread (you may open a

Re: __doc__ for functions, classes, objects etc.

On 05.09.2011 13:26, Andreas Rossberg wrote: On 4 September 2011 21:45, Brendan Eich > wrote: On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov wrote: > (1) to standardize `toString` (for this particular case -- do not remove comments inside); > > If t

Re: __doc__ for functions, classes, objects etc.

On 4 September 2011 21:45, Brendan Eich wrote: > On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov wrote: > > > (1) to standardize `toString` (for this particular case -- do not remove > comments inside); > > > > If the (1) is not possible (why by the way?), > > Because comments are not saved in the c

Re: __doc__ for functions, classes, objects etc.

On 04.09.2011 23:45, Brendan Eich wrote: On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov wrote: (1) to standardize `toString` (for this particular case -- do not remove comments inside); If the (1) is not possible (why by the way?), Because comments are not saved in the compilation process and

Re: __doc__ for functions, classes, objects etc.

On Sep 6, 2011, at 1:52 PM, Dmitry Soshnikov wrote: > (1) to standardize `toString` (for this particular case -- do not remove > comments inside); > > If the (1) is not possible (why by the way?), Because comments are not saved in the compilation process and doing so would slow parsing down an

Re: __doc__ for functions, classes, objects etc.

On 04.09.2011 0:31, Brendan Eich wrote: On Sep 6, 2011, at 12:36 AM, Dmitry Soshnikov wrote: So, IMO we can't build a "library on hacks" which we then standardize. If to implement, then the best approach at the lower level, as Python did (with processing at compilation time). I see no reason

Re: __doc__ for functions, classes, objects etc.

On 03.09.2011 22:53, Allen Wirfs-Brock wrote: On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote: https://github.com/Gozala/doc I want to second Brendan on the coolness of this. It really is a JavaScript derived solution rather than simply copying what somebody else did for some othe

Re: __doc__ for functions, classes, objects etc.

On Sep 6, 2011, at 12:36 AM, Dmitry Soshnikov wrote: > So, IMO we can't build a "library on hacks" which we then standardize. If to > implement, then the best approach at the lower level, as Python did (with > processing at compilation time). I see no reason why we can't build up a library or c

Re: __doc__ for functions, classes, objects etc.

On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote: > > https://github.com/Gozala/doc > I want to second Brendan on the coolness of this. It really is a JavaScript derived solution rather than simply copying what somebody else did for some other language. I have a couple of thoughts t

Re: __doc__ for functions, classes, objects etc.

On 03.09.2011 3:07, Brendan Eich wrote: On Sep 2, 2011, at 3:55 PM, Oliver Hunt wrote: Function.toString isn't standardised, and I recall that in the past SM did elide dead code, multiple engines reformat code, so in general this doesnt seem reliable at a library level. It also doesn't work

Re: __doc__ for functions, classes, objects etc.

On Saturday, 2011-09-03 at 24:55 , Oliver Hunt wrote: > > On Sep 2, 2011, at 3:41 PM, Brendan Eich wrote: > > On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote: > > > On Friday, 2011-09-02 at 22:28 , Brendan Eich wrote: > > > > Can you show your label hack for SpiderMonkey to es-discuss? >

Re: __doc__ for functions, classes, objects etc.

On Sep 2, 2011, at 3:55 PM, Oliver Hunt wrote: > Function.toString isn't standardised, and I recall that in the past SM did > elide dead code, multiple engines reformat code, so in general this doesnt > seem reliable at a library level. It also doesn't work for builtin > functions, and I feel

Re: __doc__ for functions, classes, objects etc.

On Sep 2, 2011, at 3:55 PM, Oliver Hunt wrote: > Function.toString isn't standardised, and I recall that in the past SM did > elide dead code, multiple engines reformat code Also _really_ old builds of JSC had "interesting" output from function.toString() > > _

Re: __doc__ for functions, classes, objects etc.

Also, mine will suffer from the same downfall noted in Oliver's comments.. "Function.toString isn't standardised, and I recall that in the past SM did elide dead code" On Fri, Sep 2, 2011 at 6:56 PM, Rick Waldron wrote: > While we're sharing... I've also written an implementation, albiet much >

Re: __doc__ for functions, classes, objects etc.

While we're sharing... I've also written an implementation, albiet much simpler in form then Dmitry's or Irakli's, but this will work in ES today as is, using old-time multi-line and single line comments. https://gist.github.com/1160879 Rick On Fri, Sep 2, 2011 at 6:41 PM, Brendan Eich wro

Re: __doc__ for functions, classes, objects etc.

On Sep 2, 2011, at 3:41 PM, Brendan Eich wrote: > On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote: > >> On Friday, 2011-09-02 at 22:28 , Brendan Eich wrote: >>> Can you show your label hack for SpiderMonkey to es-discuss? >>> >> >> Ahh sorry I did not realized I forgot to post link: >>

Re: __doc__ for functions, classes, objects etc.

On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote: > On Friday, 2011-09-02 at 22:28 , Brendan Eich wrote: >> Can you show your label hack for SpiderMonkey to es-discuss? >> > > Ahh sorry I did not realized I forgot to post link: > > https://github.com/Gozala/doc Cool! Permit me to cite so

Re: __doc__ for functions, classes, objects etc.

On Friday, 2011-09-02 at 22:28 , Brendan Eich wrote: > Can you show your label hack for SpiderMonkey to es-discuss? > Ahh sorry I did not realized I forgot to post link: https://github.com/Gozala/doc > /be > > On Sep 2, 2011, at 9:12 AM, Irakli Gozalishvili wrote: > > I also prototyped thi

__doc__ for functions, classes, objects etc.

I also prototyped this idea mainly for node. Also, I figured out a hack with a label, that make it work for spidermonkey. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France On Thursday, 2011-09-01 at 20:28

Re: __doc__ for functions, classes, objects etc.

On 01.09.2011 22:28, Dmitry A. Soshnikov wrote: On 31.08.2011 18:38, Allen Wirfs-Brock wrote: On Aug 31, 2011, at 1:57 AM, Dmitry A. Soshnikov wrote: On 30.08.2011 20:39, Allen Wirfs-Brock wrote: On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: OK, let's up the topic. Seems there are

Re: __doc__ for functions, classes, objects etc.

On 31.08.2011 18:38, Allen Wirfs-Brock wrote: On Aug 31, 2011, at 1:57 AM, Dmitry A. Soshnikov wrote: On 30.08.2011 20:39, Allen Wirfs-Brock wrote: On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: OK, let's up the topic. Seems there are no technical issues in the proposed thing -- w

Re: __doc__ for functions, classes, objects etc.

On Aug 31, 2011, at 1:57 AM, Dmitry A. Soshnikov wrote: > On 30.08.2011 20:39, Allen Wirfs-Brock wrote: >> On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: >> >>> OK, let's up the topic. Seems there are no technical issues in the proposed >>> thing -- we can simply either accept it or n

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 20:39, Allen Wirfs-Brock wrote: On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: OK, let's up the topic. Seems there are no technical issues in the proposed thing -- we can simply either accept it or not. The question is whether it's needed and sound proposal and the fea

Re: __doc__ for functions, classes, objects etc.

Dave *From:*es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Dmitry A. Soshnikov *Sent:* Tuesday, August 30, 2011 7:42 AM *To:* Rick Waldron *Cc:* Brendan Eich; es-discuss Steen *Subject:* Re: __doc__ for functions, classes, objects etc. On 30.08.2011

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 19:54, Rick Waldron wrote: On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote:

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 19:33, Dean Landolt wrote: On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote:

Re: __doc__ for functions, classes, objects etc.

On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote: > OK, let's up the topic. Seems there are no technical issues in the proposed > thing -- we can simply either accept it or not. The question is whether it's > needed and sound proposal and the feature to have in ECMAScript. There certain

RE: __doc__ for functions, classes, objects etc.

f Dmitry A. Soshnikov Sent: Tuesday, August 30, 2011 7:42 AM To: Rick Waldron Cc: Brendan Eich; es-discuss Steen Subject: Re: __doc__ for functions, classes, objects etc. On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>

Re: __doc__ for functions, classes, objects etc.

On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov < dmitry.soshni...@gmail.com> wrote: > On 30.08.2011 17:41, Rick Waldron wrote: > > On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov < > dmitry.soshni...@gmail.com> wrote: > >> OK, let's up the topic. Seems there are no technical issues i

Re: __doc__ for functions, classes, objects etc.

On Tue, Aug 30, 2011 at 10:41 AM, Dmitry A. Soshnikov < dmitry.soshni...@gmail.com> wrote: > On 30.08.2011 17:41, Rick Waldron wrote: > > On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov < > dmitry.soshni...@gmail.com> wrote: > >> OK, let's up the topic. Seems there are no technical issues i

Re: __doc__ for functions, classes, objects etc.

On 30.08.2011 17:41, Rick Waldron wrote: On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: OK, let's up the topic. Seems there are no technical issues in the proposed thing -- we can simply either accept it or not. The question is whethe

Re: __doc__ for functions, classes, objects etc.

On Tue, Aug 30, 2011 at 3:39 AM, Dmitry A. Soshnikov < dmitry.soshni...@gmail.com> wrote: > OK, let's up the topic. Seems there are no technical issues in the proposed > thing -- we can simply either accept it or not. The question is whether it's > needed and sound proposal and the feature to have

Re: __doc__ for functions, classes, objects etc.

OK, let's up the topic. Seems there are no technical issues in the proposed thing -- we can simply either accept it or not. The question is whether it's needed and sound proposal and the feature to have in ECMAScript. Some summarized features below: + Ability to get help of any built-in and a

Re: __doc__ for functions, classes, objects etc.

On 8/23/11 at 9:54, bren...@mozilla.com (Brendan Eich) wrote: 2. Before function, a la javadoc comments, or first thing in body, a la the prologue directive idea? I have found it difficult to read a Java program from top to bottom because the javadoc comments proceed the function/method hea

Re: __doc__ for functions, classes, objects etc.

On 23.08.2011 20:54, Brendan Eich wrote: A convenient notation for multiline documentation comments, with convenient reflection (*not* via toString() scraping!), would be a fine thing. Yes, exactly this -- help(...) function, and also good auto-complete of object methods helped me some time

Re: __doc__ for functions, classes, objects etc.

A convenient notation for multiline documentation comments, with convenient reflection (*not* via toString() scraping!), would be a fine thing. Some of the design dimensions: 0. Comment vs. string / quasiliteral? 1. function-only, or object literal too -- or any declaration? 2. Before function

Re: __doc__ for functions, classes, objects etc.

So, is that's all? Anyone else thinks it's a needed thing in the ES? On 22.08.2011 14:57, Dmitry A. Soshnikov wrote: On 22.08.2011 12:47, Irakli Gozalishvili wrote: I'm very much interested in getting something like this! In fact I have been useing similar documentation style for some time alre

Re: __doc__ for functions, classes, objects etc.

On 22.08.2011 12:47, Irakli Gozalishvili wrote: I'm very much interested in getting something like this! In fact I have been useing similar documentation style for some time already: function doc(lambda) { var doc = /\/\*([\s\S]*)?\*\//.exec(String(lambda)) return doc ? doc[1].trim() : '' }

Re: __doc__ for functions, classes, objects etc.

On 21.08.2011 22:26, Peter van der Zee wrote: On Sun, Aug 7, 2011 at 6:56 PM, Dmitry A. Soshnikov wrote: Hi, What about to standardize (Python's) "__doc__"-umentation comments for JS? What's the difference between that and the /** ... */ way of "JSDoc"? /** * This function does stuff *

Re: __doc__ for functions, classes, objects etc.

On Sun, Aug 7, 2011 at 6:56 PM, Dmitry A. Soshnikov wrote: > Hi, > > What about to standardize (Python's) "__doc__"-umentation comments for JS? What's the difference between that and the /** ... */ way of "JSDoc"? /** * This function does stuff * @constructor * @param {Object} foo * @returns

Re: __doc__ for functions, classes, objects etc.

This is a great idea, but I wonder if the concept could be implemented using comments as we already know them? This would leave it up to the user how they want to parse the property's value. Just a thought - either way, I think this is a valuable idea. Rick On Sun, Aug 7, 2011 at 12:56 PM, Dmit

__doc__ for functions, classes, objects etc.

Hi, What about to standardize (Python's) "__doc__"-umentation comments for JS? Not exactly in this name with underscores, but the idea itself. I remember recent discussion on Twitter where Brendan proposed to use a prologue string for that: function foo() { "this is the super function" }