Try to have it so users don't have to delete much, just extend what is
there.
On Tue, May 12, 2015 at 2:10 AM, Kasper Osterbye wrote:
> Sergio Fedi and I are now working on this.
>
> As part of the work, we need a "default package comment", akin the the
> default class comment. The class comment
On 12 maj, 2015, at 11:17 , demarey [via Smalltalk]
mailto:ml-node+s1294792n4825947...@n4.nabble.com>>
wrote:
Here I would rather see the entry point of the package: the core class(es) and
how to use it
Great - I like the term “Entry point” - just what we were looking for.
--
View this m
Le 12 mai 2015 à 06:44, Kasper Osterbye a écrit :
> stepharo wrote
>>> one line description: For example, I'm xxx package, containing the
>>> hierarchy
>>> of visitor objects.
>> What are the public main classes?
>
> There are no such thing :-) - just as there is no "private methods" in
> smallt
stepharo wrote
>> !Package XXX, part of (reference to main package if one exist)
> I did not get "
>
> (reference to main package if one exist)
>
> "
Perhaps it should be:
"!Package XXX, (part of reference to main package if one exist)"
I often see a handful of packages named "-", "XXX
Le 11/5/15 20:10, Kasper Osterbye a écrit :
Sergio Fedi and I are now working on this.
As part of the work, we need a "default package comment", akin the the
default class comment. The class comment is inspired by CRC idea.
Translating CRC to a PRC, we suggest the following, and ask for commen
Sergio Fedi and I are now working on this.
As part of the work, we need a "default package comment", akin the the
default class comment. The class comment is inspired by CRC idea.
Translating CRC to a PRC, we suggest the following, and ask for comments
from the community. As I believe we will by
Le 7/5/15 17:04, Kasper Osterbye a écrit :
Independent of package comments, the ManifestClasses are a good idea I think.
I also think they have not yet found their final design. Let me summarize my
impressions so far (perhaps this need to go to a different thread).
a) All package manifests are
Independent of package comments, the ManifestClasses are a good idea I think.
I also think they have not yet found their final design. Let me summarize my
impressions so far (perhaps this need to go to a different thread).
a) All package manifests are subclasses of "PackageManifest" - good idea.
b
Hi, as you know I’m working on QualityAssistant, and at the moment the current
structure of false positives in Manifest in not good enough for me. So I plant
to reimplement it. Should I follow some guidelines? Because you are introducing
this new package manifest, and I think that it could make
> On 6 maj, 2015, at 21:27 , Sergio Fedi [via Smalltalk]
> wrote:
>
> Does this mean that we should focus on adding the comments on this
> ManifestXXX class?
> (instead of other implementations)
Yes, that seems like the right approach to me.
I believe we could add some methods to “TheManifes
> On 6 maj, 2015, at 21:23 , stepharo [via Smalltalk]
> wrote:
>
> our idea is that each package should have meta-data:
> - default code formatting
> - false positive for rules
> - and of course package comment.
>
> So for now the simplest thing we did was to add a class cal
Does this mean that we should focus on adding the comments on this
ManifestXXX class?
(instead of other implementations)
Kasper
our idea is that each package should have meta-data:
- default code formatting
- false positive for rules
- and of course package comment.
So for now the simplest thing we did was to add a class called
ManifestXXX for packageXXX.
This way it is versionned with the classes an
2015-05-06 13:08 GMT+02:00 Marcus Denker :
>
> > On 06 May 2015, at 10:53, Christophe Demarey <
> christophe.dema...@inria.fr> wrote:
> >
> >
> > Le 5 mai 2015 à 17:14, Kasper Osterbye a écrit :
> >
> >> Marcus Denker-4 wrote
> >>> Right now we do not have yet Package comments.
> >>>
> >>> But we
Le 6 mai 2015 à 13:21, Kasper Osterbye a écrit :
> demarey wrote
>> If you want to allow package comments in Nautilus, I would display the
>> content of the description method of the package manifest if available.
>
> It would be great to leverage on something already taking place.
> Are you ta
demarey wrote
> If you want to allow package comments in Nautilus, I would display the
> content of the description method of the package manifest if available.
It would be great to leverage on something already taking place.
Are you talking about class PackageManifest?
I can see that RPackage h
> On 06 May 2015, at 10:53, Christophe Demarey
> wrote:
>
>
> Le 5 mai 2015 à 17:14, Kasper Osterbye a écrit :
>
>> Marcus Denker-4 wrote
>>> Right now we do not have yet Package comments.
>>>
>>> But we should!
>>>
>>> MBInfo seems to be a private class of Versionner…
>>>
>>> For package
Le 5 mai 2015 à 17:14, Kasper Osterbye a écrit :
> Marcus Denker-4 wrote
>> Right now we do not have yet Package comments.
>>
>> But we should!
>>
>> MBInfo seems to be a private class of Versionner…
>>
>> For package comments we first need to evaluate the design space…
>> e.g. where to stor
Sergio Fedi wrote
> If you need help, or just a buddy to tag along I can work with you.
That would likely be very nice Sergio.
I have opened a case in FogBugz
(https://pharo.fogbugz.com/f/cases/15495/Package-comments) for this.
I believe the result of this work will end up as some kind of slice.
> On 05 May 2015, at 17:14, Kasper Osterbye wrote:
>
> Marcus Denker-4 wrote
>> Right now we do not have yet Package comments.
>>
>> But we should!
>>
>> MBInfo seems to be a private class of Versionner…
>>
>> For package comments we first need to evaluate the design space…
>> e.g. where to
If you need help, or just a buddy to tag along I can work with you.
Marcus Denker-4 wrote
> Right now we do not have yet Package comments.
>
> But we should!
>
> MBInfo seems to be a private class of Versionner…
>
> For package comments we first need to evaluate the design space…
> e.g. where to store it in the image, how to store it in Monticello…
OK - Makes
Hello,
Right now we do not have yet Package comments.
But we should!
MBInfo seems to be a private class of Versionner…
For package comments we first need to evaluate the design space…
e.g. where to store it in the image, how to store it in Monticello…
Marcus
> On 04 May 2015, at 18:
I know little about the subject but Packages have been until recently only
Strings.
Now they were reified as objects, but as far as I saw, these objects didn't
have comments as a part of them.
In the Nautilus browser I have been working a bit on allowing Pillar for
class comments. When browsing that part of Nautilus, I notice that there are
some hooks for package comments in the getComments and addComments methods.
Is there a history of "package comments" somewhere in the system? I was
25 matches
Mail list logo
