Le 16/9/16 à 13:42, Clément Bera a écrit :
Why don't you just change nautilus to have two text areas, one with the test corresponding to the method and the other one with the method's code ?

You're saying:
/Their values is active documentation that can be automatically validated./ That can also be applied to test we've already had with SUnit. If the only difference you want is to display the test next to the method, then it's an IDE problem, nothing has to be changed but the IDE.

and you want to create different semantic objects... well you underestimate the amount of work. Ask pavel just to get a semantically model for Pharo just plain pharo with Slot and Traits.


In python they have no other choices than putting tests in comments because their IDE is a text editor, they cannot create other panes or anything like that.

Clement how do you save/store/merge....
in a method it is cheap and working.

On Fri, Sep 16, 2016 at 1:21 PM, stepharo <steph...@free.fr <mailto:steph...@free.fr>> wrote:


    I was thinking on the metro way to work, and I also saw that this
    discussion is actually split in multiple threads, so it was not
    easy to follow :).

    Some of my feelings about this:

    - Pragmas are nice because they are easy to "interpret". Parsing
    them is already provided. However, putting expressions or long
    examples into them starts to be awkward. It seems it's pushin the
    syntax too much, isn't it?

    - Comments are nice because they are ignored! But right now
    comments are simple plain text. This thread is to convert *some*
    comments into executable examples. But this should be just some
    comments and not all of them, am I right? So what happens when we
    want to have comments written in Pillar for example? What I mean
    is that having examples is just an example of something we would
    like to do with comments.

    But we can also imagine having comment interpreters. Something
    like this:

    !This is a Pillar title
    And I'm just a paragraph
    And I can link a class like @Object.

    self assert: '/foo/gloops.taz' asFileReference basename equals:

    We could have for class comment

    UMLClass named: 'Visitor'

    Arrow from:

    But this can start to be complex

    What I like from this is that:
      - comments that do not specify an interpreter are just plain
    old text. Thus backward compatible.
      - comments that specify an interpreter that is not present, are
    just plain old text. A decoupling as it happens with the settings.
      - an ExampleDoc interpreter can be just a test case instance,
    thus we could use assertions instead of special >>> messages.
    I do not know because all the comments should be pillar compatible.
    If you do not use pillar commands you just get plain text.
    You see we can easily detect comment too: if a text contains >>>
    then it is a doc

    is an extra syntax.

    I'm not found with the
        self assert:
    because it feels like something coming out of nowhere. We will
    have to explain: yes self is bound to an instance of the testCase...
    and to me this is implementation details:
        if I give expr1 and expr2 the implementation can build self
    assert: expr1 equals: expr2

    I liked the simplicity of nicolai' solution
    I would just have a comment and a message >>> so that we
        => nearly no syntax change
        => something really lightweight and optional

    What I care is that

        - we get simple examples right in the method
        - one line no more.
        - that these examples are correct and always validated (I do
    not see them as tests), their values is more in the correct
        than the tests. They are basic output. I do not want to have
    full code in the method, in that case this should go one class
    side example
        or plain tests.

    Things that would require more thought:
      - there is an overlap between these interpreted comments and
    pragmas... There are for sure cases that solutions can be
    imagined with both.
    I do not think that expressions can fit inside pragmas
      - there is an overlap between examples and test cases. I saw
    many people that argued that already. I am not against examples,
    but I think we should (whichever implementation is chosen) draw a
    line and set some guidelines.
    To me I do not care that they are tests.
    Their values is active documentation that can be automatically
    validated. I do not expect to run them but the system
    can garantee that they are correct.

    Stef, probably you have already in mind when you want a test case
    and when an example and what's the distance. It would be good if
    we can transform that implicit thought in something explicit
    (maybe even a lint rule in the future?)
    I do not get what you mean here.

    For me a test is a scenario.
        If I do that and that then this happens
        a test can use a class example

    Now for me a test should not rely one a online part of method

    These onliners are just make the method comments better.


    -------- Original Message --------

    Hi nicolai

    I was thinking that I would prefer to have

        "` '/foo/gloops.taz' asFileReference basename -> 'gloops.taz'.`"

    instead of
        ` '/foo/gloops.taz' asFileReference basename ->
    'gloops.taz'.` <- suceeds, no output

    So that we can use ` in the future in plain code.
    Also it has the advantage that it is backward compatible.

    Else we could have

    But I do not know.

    Tell me what you think.

    I would love to browse the complete system to convert existing
    one liner with such


    Ok, this is a quick hack ( do not look at the code :), yes
    using regex here is a bit fragil)

    You can add code in comments between backticks (`)
    The formatter will highlight the text like smalltalk code (or
    not if it is not valid code).
    + an icon styler with an icon showing a warning icon for faulty
    code or an information icon otherwise
    you can click on the icon,

    if the code is an association

    expression -> result

    it executes the expression and compares it with the result,
    (with assert:equals: ) opens debugger if it fails and does
    nothing otherwise

    if the code is just an expression, it opens an inspector.

    This is just one way to do some tests and experiments with this
    idea, don 't yet know if this is a good idea or if
    we can / should find a better way to connect code with examples.

    first result, I find expressions in comments, highlighted as
    code, confusing :)

    (file in attached cs in a recent pharo 6.0 and look at the
    method AbstractFileReference>>#baseName . Or
    add an expression with backticks in a method comment
    ` your code here `


Reply via email to