[Gambas-user] Restructuring the official Gambas examples

Sebastian Kulesz sebikul at ...626...
Tue Apr 30 22:33:16 CEST 2013


On Apr 30, 2013 5:23 PM, "Tobias Boege" <taboege at ...626...> wrote:
>
> On Tue, 30 Apr 2013, Sebastian Kulesz wrote:
> > Maybe there is a way to do this already without changing anything.
Consider
> > this:
> >
> > The complexity of an example (project?) *may* be given by the amount of
> > components it uses (just thinking out loud). But, if not accurate, it
> > should be a really good approximation.
> >
> > So, sorting the examples by the amount of components it uses may be a
short
> > therm solution for this, if not a permanent one, until a consensus is
> > reached.
> >
> > A slight change to the previous approach: assign each component a
numerical
> > difficulty and then compute the final score by adding the value of each
> > component used. Then sort them using that value. We would then only
need to
> > assess the difficulty of using each component.
> >
> > I know this is not the most accurate solution, but it's much less
> > intrusive.
>
> Wait, how do we assign each component a numerical difficulty level? OK, we
> have the *.component files but that seems even more intrusive. IMHO more
> difficult to rate either. Having "Beginner" and "Advanced" in examples
makes
> it feasible that everybody classifies his examples himself.
>
> I can only precisely speak about the example I wrote: look at Games/Pong.
It
> only requires gb.ncurses and is complex as hell. OK, admittedly gb.ncurses
> wouldn't climb too high on the easy-to-use ladder but that can't
compensate
> using three to four graphical components like some other games do.
>
> You see: "Games" tend to always be more complex than "Basic" examples and
> that's why I want to conserve the topic grouping.
>
> On the other side, of course, the biggest example, the IDE itself, does
> somewhat support your idea.
>
> If we go and rate the project structure, maybe the number of classes is
> better, but IMHO still the explicit, human-chosen grouping is best.
>

That's why I said this wasn't the most accurate approach. Ratings can
easily be added to the IDE (just as components descriptions), there is no
need to modify any .component file.

Doing it this way, classes, amount of symbols, amount of forms...there are
a lot of variables that will allow you to calculate the difficulty of any
project, not just examples.

As you said, GB.nurses will increase the difficulty value more than GB.form
Stock would do, for example. That's why I suggested rating components
rather than examples, there is no need to review every new example that is
added, and doing so imposes less changes to be done to the IDE.

> Regards,
> Tobi
>
>
------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user



More information about the User mailing list