f



some thought on expressing function organistation

maybe i should not start whole thread to this but cannot find a place to glue this

the idea is based on that that in c you got a lot of plain 
functions where it is not quite possible to express some
in-program function relations (you must sorta like reverse
engineer the code to know that and its not so quite easy)

some wondered if function defined in body of parent functions
could be helpfull but it brings some unconveniencies (the parent function gets bloated)

incidentally i found other idea, it is to use the parent function name as a first part of name using dot

it is like:

RunShips.Drawships.DrawShip();
RunShips.MoveShips.CheckCollision.MakeVicinityList();
RunShips();

something like that... I think the idea could be somewhat extended, it is more writing, but gives more info and orientation on general program structure 

the calls should be probably without all this parent names,
also the depth of how far some want to draw this names probably could be to freely chose maybe
one could for example write all like 
mian.GameLoop.RunFrame.RunShips.MoveShips.CheckCollision.MakeVicinityList();
 or only shorter part - but overall it is interesting
0
fir
12/21/2016 6:35:25 PM
comp.lang.c 30656 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

6 Replies
781 Views

Similar Articles

[PageSpeed] 8

You're a moron. And I can safely say you will never have what it takes to write software for a living.
0
Chad
12/21/2016 8:24:14 PM
On Wednesday, December 21, 2016 at 12:35:38 PM UTC-6, fir wrote:
> maybe i should not start whole thread to this but cannot find a place to 

[snip]

> incidentally i found other idea, it is to use the parent function name as a first part of name using dot
> 
> it is like:
> 
> RunShips.Drawships.DrawShip();
> RunShips.MoveShips.CheckCollision.MakeVicinityList();
> RunShips();
> 

Currently, we just fake namespaces using an underscore instead of a dot:

    T MyFakeNamespace_func( );
    T MyFakeNamespace_MyFakeInnerNamespace_func( );

etc.  

That's actually an interesting idea though, now that I think about it - sort
of like a weird class system, but just for functions.  

I can kind of see a definition like

    T OuterFunc( /* parameter list */ )
    {
      /**
       * Declarations of inner functions
       */
      U InnerFunc( /* parameter list */ );
      V AnotherInnerFunc( /* parameter list */ );

      // OuterFunc body

      if ( InnerFunc() == some_value )
        AnotherInnerFunc();
    }

    /**
     * Definitions of functions local to OuterFunc
     */
    U OuterFunc.InnerFunc( /* parameter list */ )
    {
      // InnerFunc body
    }

Both InnerFunc and AnotherInnerFunc are only visible to and callable from
OuterFunc.  Objects declared within the body of OuterFunc would be visible
to InnerFunc and AnotherInnerFunc.

Obviously, this will never make its way into C (requires a much higher-
level approach to function types than C allows for), but it is an
interesting idea.
0
John
12/21/2016 10:40:20 PM
W dniu =C5=9Broda, 21 grudnia 2016 23:40:27 UTC+1 u=C5=BCytkownik John Bode=
 napisa=C5=82:
> On Wednesday, December 21, 2016 at 12:35:38 PM UTC-6, fir wrote:
> > maybe i should not start whole thread to this but cannot find a place t=
o=20
>=20
> [snip]
>=20
> > incidentally i found other idea, it is to use the parent function name =
as a first part of name using dot
> >=20
> > it is like:
> >=20
> > RunShips.Drawships.DrawShip();
> > RunShips.MoveShips.CheckCollision.MakeVicinityList();
> > RunShips();
> >=20
>=20
> Currently, we just fake namespaces using an underscore instead of a dot:
>=20
>     T MyFakeNamespace_func( );
>     T MyFakeNamespace_MyFakeInnerNamespace_func( );
>=20
> etc. =20
>=20
> That's actually an interesting idea though, now that I think about it - s=
ort
> of like a weird class system, but just for functions. =20
>=20
> I can kind of see a definition like
>=20
>     T OuterFunc( /* parameter list */ )
>     {
>       /**
>        * Declarations of inner functions
>        */
>       U InnerFunc( /* parameter list */ );
>       V AnotherInnerFunc( /* parameter list */ );
>=20
>       // OuterFunc body
>=20
>       if ( InnerFunc() =3D=3D some_value )
>         AnotherInnerFunc();
>     }
>=20
>     /**
>      * Definitions of functions local to OuterFunc
>      */
>     U OuterFunc.InnerFunc( /* parameter list */ )
>     {
>       // InnerFunc body
>     }
>=20
> Both InnerFunc and AnotherInnerFunc are only visible to and callable from
> OuterFunc.  Objects declared within the body of OuterFunc would be visibl=
e
> to InnerFunc and AnotherInnerFunc.
>=20
> Obviously, this will never make its way into C (requires a much higher-
> level approach to function types than C allows for), but it is an
> interesting idea.

the thing im saying could theoretically be added (its optional and works mo=
stly as a commentary with compile time checking) but should not be added - =
old c is holy thing=20
should not be modified (except maybe damn const related stupidities)=20
but this idea is to be considered in more general c related spirit=20
0
fir
12/21/2016 10:55:25 PM
W dniu =C5=9Broda, 21 grudnia 2016 23:55:42 UTC+1 u=C5=BCytkownik fir napis=
a=C5=82:
> W dniu =C5=9Broda, 21 grudnia 2016 23:40:27 UTC+1 u=C5=BCytkownik John Bo=
de napisa=C5=82:
> > On Wednesday, December 21, 2016 at 12:35:38 PM UTC-6, fir wrote:
> > > maybe i should not start whole thread to this but cannot find a place=
 to=20
> >=20
> > [snip]
> >=20
> > > incidentally i found other idea, it is to use the parent function nam=
e as a first part of name using dot
> > >=20
> > > it is like:
> > >=20
> > > RunShips.Drawships.DrawShip();
> > > RunShips.MoveShips.CheckCollision.MakeVicinityList();
> > > RunShips();
> > >=20
> >=20
> > Currently, we just fake namespaces using an underscore instead of a dot=
:
> >=20
> >     T MyFakeNamespace_func( );
> >     T MyFakeNamespace_MyFakeInnerNamespace_func( );
> >=20
> > etc. =20
> >=20
> > That's actually an interesting idea though, now that I think about it -=
 sort
> > of like a weird class system, but just for functions. =20
> >=20
> > I can kind of see a definition like
> >=20
> >     T OuterFunc( /* parameter list */ )
> >     {
> >       /**
> >        * Declarations of inner functions
> >        */
> >       U InnerFunc( /* parameter list */ );
> >       V AnotherInnerFunc( /* parameter list */ );
> >=20
> >       // OuterFunc body
> >=20
> >       if ( InnerFunc() =3D=3D some_value )
> >         AnotherInnerFunc();
> >     }
> >=20
> >     /**
> >      * Definitions of functions local to OuterFunc
> >      */
> >     U OuterFunc.InnerFunc( /* parameter list */ )
> >     {
> >       // InnerFunc body
> >     }
> >=20
> > Both InnerFunc and AnotherInnerFunc are only visible to and callable fr=
om
> > OuterFunc.  Objects declared within the body of OuterFunc would be visi=
ble
> > to InnerFunc and AnotherInnerFunc.
> >=20
> > Obviously, this will never make its way into C (requires a much higher-
> > level approach to function types than C allows for), but it is an
> > interesting idea.
>=20
> the thing im saying could theoretically be added (its optional and works =
mostly as a commentary with compile time checking) but should not be added =
- old c is holy thing=20
> should not be modified (except maybe damn const related stupidities)=20
> but this idea is to be considered in more general c related spirit

the one thing yet comes to mind is static data related to thiose branches f=
or example in my game prototypes o get
modules like allies.c enemy-ships.c bullets.c each module has its entry bra=
nch point (RunAllies(), RunEnemyShips(), RunBullets()) and each own static =
data (arrays) which are accessed mostly "down the branch" (main() i conside=
r being up)   - here in this branch scheme it would be nice to 'ally' those=
 static data with this branches too, maybe - but im not sure how and maybe =
some things would need to be rethinked, as sometimes one branch may acces t=
he another (like ally fires the bullet)  (this is in genereal 'rare' though=
, i mean code quite often lays "down the branch only", and if no maybe it i=
s worth to specially denote this cases (so maybe this naming scheme could b=
e also used for that) - i will probably check that
=20
0
fir
12/21/2016 11:41:41 PM
W dniu =C5=9Broda, 21 grudnia 2016 19:35:38 UTC+1 u=C5=BCytkownik fir napis=
a=C5=82:
> maybe i should not start whole thread to this but cannot find a place to =
glue this
>=20
> the idea is based on that that in c you got a lot of plain=20
> functions where it is not quite possible to express some
> in-program function relations (you must sorta like reverse
> engineer the code to know that and its not so quite easy)
>=20
> some wondered if function defined in body of parent functions
> could be helpfull but it brings some unconveniencies (the parent function=
 gets bloated)
>=20
> incidentally i found other idea, it is to use the parent function name as=
 a first part of name using dot
>=20
> it is like:
>=20
> RunShips.Drawships.DrawShip();
> RunShips.MoveShips.CheckCollision.MakeVicinityList();
> RunShips();
>=20
> something like that... I think the idea could be somewhat extended, it is=
 more writing, but gives more info and orientation on general program struc=
ture=20
>=20
> the calls should be probably without all this parent names,
> also the depth of how far some want to draw this names probably could be =
to freely chose maybe
> one could for example write all like=20
> mian.GameLoop.RunFrame.RunShips.MoveShips.CheckCollision.MakeVicinityList=
();
>  or only shorter part - but overall it is interesting

this could also allow to read the program source by its page of contents - =
it is function declarations page, alone
function name dont say to much as this not describes tge function place in =
a code bush, but here experienced=20
coder probably could mayb even judge the program by this contents pages

0
fir
12/22/2016 12:34:03 AM
W dniu czwartek, 22 grudnia 2016 00:41:56 UTC+1 u=C5=BCytkownik fir napisa=
=C5=82:
> W dniu =C5=9Broda, 21 grudnia 2016 23:55:42 UTC+1 u=C5=BCytkownik fir nap=
isa=C5=82:
> > W dniu =C5=9Broda, 21 grudnia 2016 23:40:27 UTC+1 u=C5=BCytkownik John =
Bode napisa=C5=82:
> > > On Wednesday, December 21, 2016 at 12:35:38 PM UTC-6, fir wrote:
> > > > maybe i should not start whole thread to this but cannot find a pla=
ce to=20
> > >=20
> > > [snip]
> > >=20
> > > > incidentally i found other idea, it is to use the parent function n=
ame as a first part of name using dot
> > > >=20
> > > > it is like:
> > > >=20
> > > > RunShips.Drawships.DrawShip();
> > > > RunShips.MoveShips.CheckCollision.MakeVicinityList();
> > > > RunShips();
> > > >=20
> > >=20
> > > Currently, we just fake namespaces using an underscore instead of a d=
ot:
> > >=20
> > >     T MyFakeNamespace_func( );
> > >     T MyFakeNamespace_MyFakeInnerNamespace_func( );
> > >=20
> > > etc. =20
> > >=20
> > > That's actually an interesting idea though, now that I think about it=
 - sort
> > > of like a weird class system, but just for functions. =20
> > >=20
> > > I can kind of see a definition like
> > >=20
> > >     T OuterFunc( /* parameter list */ )
> > >     {
> > >       /**
> > >        * Declarations of inner functions
> > >        */
> > >       U InnerFunc( /* parameter list */ );
> > >       V AnotherInnerFunc( /* parameter list */ );
> > >=20
> > >       // OuterFunc body
> > >=20
> > >       if ( InnerFunc() =3D=3D some_value )
> > >         AnotherInnerFunc();
> > >     }
> > >=20
> > >     /**
> > >      * Definitions of functions local to OuterFunc
> > >      */
> > >     U OuterFunc.InnerFunc( /* parameter list */ )
> > >     {
> > >       // InnerFunc body
> > >     }
> > >=20
> > > Both InnerFunc and AnotherInnerFunc are only visible to and callable =
from
> > > OuterFunc.  Objects declared within the body of OuterFunc would be vi=
sible
> > > to InnerFunc and AnotherInnerFunc.
> > >=20
> > > Obviously, this will never make its way into C (requires a much highe=
r-
> > > level approach to function types than C allows for), but it is an
> > > interesting idea.
> >=20
> > the thing im saying could theoretically be added (its optional and work=
s mostly as a commentary with compile time checking) but should not be adde=
d - old c is holy thing=20
> > should not be modified (except maybe damn const related stupidities)=20
> > but this idea is to be considered in more general c related spirit
>=20
> the one thing yet comes to mind is static data related to thiose branches=
 for example in my game prototypes o get
> modules like allies.c enemy-ships.c bullets.c each module has its entry b=
ranch point (RunAllies(), RunEnemyShips(), RunBullets()) and each own stati=
c data (arrays) which are accessed mostly "down the branch" (main() i consi=
der being up)   - here in this branch scheme it would be nice to 'ally' tho=
se static data with this branches too, maybe - but im not sure how and mayb=
e some things would need to be rethinked, as sometimes one branch may acces=
 the another (like ally fires the bullet)  (this is in genereal 'rare' thou=
gh, i mean code quite often lays "down the branch only", and if no maybe it=
 is worth to specially denote this cases (so maybe this naming scheme could=
 be also used for that) - i will probably check that

example of the thing to consider would be for example:

in bullets module i gut such functions as=20

RunBullets() (which is entry point), =20
RunBullets.InitBullets()
RunBullets.MoveBullets()
RunBullets.DrawBullets()
and down the branch of that=20

but i aslo had AddBulet() which adds bullet to container/ creates bullet - =
this one could be called by RunBullets.InitBullets() if i would like to get=
 some bullets fired at start (most cases probably none) but
will be also called form allies.c (somewhere down RunAllies.MoveAllies() ) =
and enemy-ships.c=20
(and maybe more) so its worth maybe considering how to denothe this

- it seems that not providing function path for this is=20
already informative (those with not provided could be
considered as those multiparent ones).. though on the=20
other side as it like "phyciscally" belongs to RunBullets
(or maybe InitBUllets?) branch maybe it should be also=20
pathed as RunBullets.AddBullet() even thought it is not=20
normally caled form runBUllets - this is reisky but may be considered ) - a=
nd then make this full path in calling places maybe (?) - a bit hard to say=
)
0
fir
12/22/2016 12:46:26 AM
Reply: