Idea to manager package comment in better way

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Idea to manager package comment in better way

Denis Kudriashov
Hi.

I look at hierarchy of PackageManifest and I was wondering that all these classes are commented but most of packages which they describe are not.

Also interesting that most of manifest comments are same. 

Then I found that package comment is managed as special class side method #description which is generated when you call "aPackage packageComment: 'test'".

Now the idea: will not it be better to manage package comment as manifest class comment?

Manifest is already responsible to describe the package. So it looks logical to have "manifest comment = package comment". 
Also it will simplify code and remove duplication of texts.
In addition it will add extra place indicating that package needs to be commented because uncommented classes are marked in the browser.

What you think?

Reply | Threaded
Open this post in threaded view
|

Re: Idea to manager package comment in better way

Denis Kudriashov
And I found that manifest classes are already commented as package comment.

2018-03-14 16:40 GMT+01:00 Denis Kudriashov <[hidden email]>:
Hi.

I look at hierarchy of PackageManifest and I was wondering that all these classes are commented but most of packages which they describe are not.

Also interesting that most of manifest comments are same. 

Then I found that package comment is managed as special class side method #description which is generated when you call "aPackage packageComment: 'test'".

Now the idea: will not it be better to manage package comment as manifest class comment?

Manifest is already responsible to describe the package. So it looks logical to have "manifest comment = package comment". 
Also it will simplify code and remove duplication of texts.
In addition it will add extra place indicating that package needs to be commented because uncommented classes are marked in the browser.

What you think?


Reply | Threaded
Open this post in threaded view
|

Re: Idea to manager package comment in better way

Marcus Denker-4
In reply to this post by Denis Kudriashov


> On 14 Mar 2018, at 16:40, Denis Kudriashov <[hidden email]> wrote:
>
> Hi.
>
> I look at hierarchy of PackageManifest and I was wondering that all these classes are commented but most of packages which they describe are not.
>
> Also interesting that most of manifest comments are same.
>
> Then I found that package comment is managed as special class side method #description which is generated when you call "aPackage packageComment: 'test'".
>
> Now the idea: will not it be better to manage package comment as manifest class comment?
>
> Manifest is already responsible to describe the package. So it looks logical to have "manifest comment = package comment".
> Also it will simplify code and remove duplication of texts.
> In addition it will add extra place indicating that package needs to be commented because uncommented classes are marked in the browser.
>
> What you think?
>
I would say yes… this would save actually space: lots of methods removed, and the string would be stored on disk instead
of inside the image.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Idea to manager package comment in better way

Denis Kudriashov
In reply to this post by Denis Kudriashov
And at the end I found that #packageComment: is not really work because it expects already formatted string suitable for source code insertion.
So you can't  just call: 

aPackage packageComment: 'my comment'.

Instead all users (only Nautilus exists) should write 

aPackage packageComment: 'my comment' printString

I will create pull request with all this changes

2018-03-14 16:51 GMT+01:00 Denis Kudriashov <[hidden email]>:
And I found that manifest classes are already commented as package comment.

2018-03-14 16:40 GMT+01:00 Denis Kudriashov <[hidden email]>:
Hi.

I look at hierarchy of PackageManifest and I was wondering that all these classes are commented but most of packages which they describe are not.

Also interesting that most of manifest comments are same. 

Then I found that package comment is managed as special class side method #description which is generated when you call "aPackage packageComment: 'test'".

Now the idea: will not it be better to manage package comment as manifest class comment?

Manifest is already responsible to describe the package. So it looks logical to have "manifest comment = package comment". 
Also it will simplify code and remove duplication of texts.
In addition it will add extra place indicating that package needs to be commented because uncommented classes are marked in the browser.

What you think?



Reply | Threaded
Open this post in threaded view
|

Re: Idea to manager package comment in better way

Stephane Ducasse-3
Hi denis

Both solutions are ok for me.

STef

On Fri, Mar 16, 2018 at 2:38 PM, Denis Kudriashov <[hidden email]> wrote:

> And at the end I found that #packageComment: is not really work because it
> expects already formatted string suitable for source code insertion.
> So you can't  just call:
>
> aPackage packageComment: 'my comment'.
>
> Instead all users (only Nautilus exists) should write
>
> aPackage packageComment: 'my comment' printString
>
> I will create pull request with all this changes
>
> 2018-03-14 16:51 GMT+01:00 Denis Kudriashov <[hidden email]>:
>>
>> And I found that manifest classes are already commented as package
>> comment.
>>
>> 2018-03-14 16:40 GMT+01:00 Denis Kudriashov <[hidden email]>:
>>>
>>> Hi.
>>>
>>> I look at hierarchy of PackageManifest and I was wondering that all these
>>> classes are commented but most of packages which they describe are not.
>>>
>>> Also interesting that most of manifest comments are same.
>>>
>>> Then I found that package comment is managed as special class side method
>>> #description which is generated when you call "aPackage packageComment:
>>> 'test'".
>>>
>>> Now the idea: will not it be better to manage package comment as manifest
>>> class comment?
>>>
>>> Manifest is already responsible to describe the package. So it looks
>>> logical to have "manifest comment = package comment".
>>> Also it will simplify code and remove duplication of texts.
>>> In addition it will add extra place indicating that package needs to be
>>> commented because uncommented classes are marked in the browser.
>>>
>>> What you think?
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Idea to manager package comment in better way

Denis Kudriashov
I created issue 21617

2018-03-16 16:54 GMT+01:00 Stephane Ducasse <[hidden email]>:
Hi denis

Both solutions are ok for me.

STef

On Fri, Mar 16, 2018 at 2:38 PM, Denis Kudriashov <[hidden email]> wrote:
> And at the end I found that #packageComment: is not really work because it
> expects already formatted string suitable for source code insertion.
> So you can't  just call:
>
> aPackage packageComment: 'my comment'.
>
> Instead all users (only Nautilus exists) should write
>
> aPackage packageComment: 'my comment' printString
>
> I will create pull request with all this changes
>
> 2018-03-14 16:51 GMT+01:00 Denis Kudriashov <[hidden email]>:
>>
>> And I found that manifest classes are already commented as package
>> comment.
>>
>> 2018-03-14 16:40 GMT+01:00 Denis Kudriashov <[hidden email]>:
>>>
>>> Hi.
>>>
>>> I look at hierarchy of PackageManifest and I was wondering that all these
>>> classes are commented but most of packages which they describe are not.
>>>
>>> Also interesting that most of manifest comments are same.
>>>
>>> Then I found that package comment is managed as special class side method
>>> #description which is generated when you call "aPackage packageComment:
>>> 'test'".
>>>
>>> Now the idea: will not it be better to manage package comment as manifest
>>> class comment?
>>>
>>> Manifest is already responsible to describe the package. So it looks
>>> logical to have "manifest comment = package comment".
>>> Also it will simplify code and remove duplication of texts.
>>> In addition it will add extra place indicating that package needs to be
>>> commented because uncommented classes are marked in the browser.
>>>
>>> What you think?
>>>
>>
>