On 12 maj, 2015, at 11:17 , demarey [via Smalltalk]
ml-node+s1294792n4825947...@n4.nabble.commailto: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
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
smalltalk.
But in
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 kas...@itu.dk 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
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 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
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
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
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)
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.
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 store it in the
On 05 May 2015, at 17:14, Kasper Osterbye kas...@itu.dk 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
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 talking
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 should!
MBInfo seems to be a private class of Versionner…
For package
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
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
On 6 maj, 2015, at 21:23 , stepharo [via Smalltalk]
ml-node+s1294792n4824878...@n4.nabble.com 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
On 6 maj, 2015, at 21:27 , Sergio Fedi [via Smalltalk]
ml-node+s1294792n4824882...@n4.nabble.com 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
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 sense.
If you need help, or just a buddy to tag along I can work with you.
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
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
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.
23 matches
Mail list logo
