1. Forum
  2. Usenet
  3. COMP.LANG.C

  • theorethical thought on tree structure, fields, tags and so called tag

    From fir@21:1/5 to All on Sun Aug 25 16:17:22 2024
    [i added teh tag oryginal - as in fact most of what i write aroound c
    language theory are oryginal thoughts, not something that i just read or
    seen somewhere - to be clear)

    i thought a bot on things like that

    some {

    void a() {}
    void b() {}
    }

    some2 {

    void a() {}
    void b() {}
    }

    and soem obserwation is its probably more convenient to
    write

    void some.a() {}
    void some.b() {}
    void some2.a() {}
    void some2.b() {}

    wchich my be seen as critique of this module {} convention
    (where opening s far to closing

    then you can call foo(some) or foo(some2) for some advantage

    but if so this convention will probably build a tree
    structure over the fields and i once noticed tree
    structure is not best for some things (liek in need
    for soem things people calls polymorphism)

    it seems something i call 'tags' is better - it is
    situation ehen given thing has more than one parent
    but im not sure how to 'bite' this

    say soem example

    car.wheels
    car.doors
    car.engine
    car.move()

    boat.engine
    boat.turbine
    boat.move()

    car is vehicle, and say when car in programming
    world is full structure the vehicle is probably more
    the interface that car should give as its vehicle

    so "vehicle" is something other than auperfield
    (or how to call it) it must be something other,
    maybe i should call it tags

    im not in mood to write on it more today (not much good
    form and focus) but from this whai i write imo
    teh conclusion is probably - treelike structures and fields
    are not enough to do what is called polymorphism
    (and soem interface related things) so there is a need
    of define soem "tag system" probably aside of that

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)