Design philosophy
13 views
Skip to first unread message
Mingun
Nov 17, 2010, 3:07:35 AM11/17/10
to scite-interest
For engaging of new forces, I suggest to describe a few receptions
which are used at programming SciTE. Much to my regret very few
projects describe, they use what idioms and why. And I know only one
project which will understand to the new developer easily - OGRE.
Apparently, SciTE gets to the sad list of projects where new forces
should master lonely open spaces of the code in loneliness... Almost
deprived of any comments.
So, on the sly we will start.
Messages.
SciTE uses the mechanism of messages (as it uses Scintilla). It means
that if you need to add any specific singularity which is in a
revolutionary way new in SciTE, you should create the new message and
to process it in one of several functions on message handling. In view
of that some functions are caused at present indirectly (under their
pointer stored as a member of the data of a class), at code research
(which is necessary for leading as documentation aren't present) it is
necessary to try. The blessing, NetBeans possesses the most powerful
editor who has helped me not to be tangled with these artful designs
of the code.
Past trends.
At the editor are tracked very deep C-origins in the form of usage of
the mechanism of pointers on functions, usage of structures instead of
classes and implementation of COM-mechanisms in typical C-style, i.e.
with manual creation of the table of virtual functions. Since version
2.0 the interface of lexers has undergone the considerable changes, it
to become more a C++-directed:
New interfaces.
In particular, there were interfaces ILexer and IDocument. Now lexer
functions are implemented as functions-members of the class inherited
from ILexer, but the overwhelming majority of lexers still I use the
old mechanism with pointers on function. Unfortunately, new interfaces
too aren't documented in any way. For example, I have clarified,
function ILexer::PrivateCall(...) has no relation to actually lexical
scan of the document, and is caused as the output agent of messages of
the editor. Here we see one more lack of C-style: absence typesafed
parameters. If instead of #define would be used enum even without the
documentation it would be easy to understand, what parameters are
required functions and that approximately it should do. I hope, soon
the situation to be corrected.
Range.
Earlier (and now, but earlier it was unique) Scintilla was used data
structure Sci_CharacterRange, defined as CharacterRange. Beginning
somewhere with version 2.0 there was new class Range, on sense and
structure similar CharacterRange. Data types with long on int
(typedef'ed on Position) have changed only. On the other hand, this
class isn't entered in Scincilla.h and consequently while it is
necessary to use CharacterRange for exterior projects.
Original message (in Russian) placed here: http://www.scite-ru.org/viewtopic.php?f=11&t=43
Sorry for my English - this is autotranslating from Russian.
which are used at programming SciTE. Much to my regret very few
projects describe, they use what idioms and why. And I know only one
project which will understand to the new developer easily - OGRE.
Apparently, SciTE gets to the sad list of projects where new forces
should master lonely open spaces of the code in loneliness... Almost
deprived of any comments.
So, on the sly we will start.
Messages.
SciTE uses the mechanism of messages (as it uses Scintilla). It means
that if you need to add any specific singularity which is in a
revolutionary way new in SciTE, you should create the new message and
to process it in one of several functions on message handling. In view
of that some functions are caused at present indirectly (under their
pointer stored as a member of the data of a class), at code research
(which is necessary for leading as documentation aren't present) it is
necessary to try. The blessing, NetBeans possesses the most powerful
editor who has helped me not to be tangled with these artful designs
of the code.
Past trends.
At the editor are tracked very deep C-origins in the form of usage of
the mechanism of pointers on functions, usage of structures instead of
classes and implementation of COM-mechanisms in typical C-style, i.e.
with manual creation of the table of virtual functions. Since version
2.0 the interface of lexers has undergone the considerable changes, it
to become more a C++-directed:
New interfaces.
In particular, there were interfaces ILexer and IDocument. Now lexer
functions are implemented as functions-members of the class inherited
from ILexer, but the overwhelming majority of lexers still I use the
old mechanism with pointers on function. Unfortunately, new interfaces
too aren't documented in any way. For example, I have clarified,
function ILexer::PrivateCall(...) has no relation to actually lexical
scan of the document, and is caused as the output agent of messages of
the editor. Here we see one more lack of C-style: absence typesafed
parameters. If instead of #define would be used enum even without the
documentation it would be easy to understand, what parameters are
required functions and that approximately it should do. I hope, soon
the situation to be corrected.
Range.
Earlier (and now, but earlier it was unique) Scintilla was used data
structure Sci_CharacterRange, defined as CharacterRange. Beginning
somewhere with version 2.0 there was new class Range, on sense and
structure similar CharacterRange. Data types with long on int
(typedef'ed on Position) have changed only. On the other hand, this
class isn't entered in Scincilla.h and consequently while it is
necessary to use CharacterRange for exterior projects.
Original message (in Russian) placed here: http://www.scite-ru.org/viewtopic.php?f=11&t=43
Sorry for my English - this is autotranslating from Russian.
Remi Gillig
Nov 17, 2010, 6:26:26 AM11/17/10
to scite-i...@googlegroups.com
That does not make much sense, auto translation is evil. Try finding someone to translate please.
"Apparently, SciTE gets to the sad list of projects where new forces should master lonely open spaces of the code in loneliness..." That eludes me for example.
Rémi Gillig.
"Apparently, SciTE gets to the sad list of projects where new forces should master lonely open spaces of the code in loneliness..." That eludes me for example.
Rémi Gillig.
--
You received this message because you are subscribed to the Google Groups "scite-interest" group.
To post to this group, send email to scite-i...@googlegroups.com.
To unsubscribe from this group, send email to scite-interes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en.
steve donovan
Nov 17, 2010, 6:39:42 AM11/17/10
to scite-i...@googlegroups.com
On Wed, Nov 17, 2010 at 1:26 PM, Remi Gillig <remig...@gmail.com> wrote:
> "Apparently, SciTE gets to the sad list of projects where new forces should
> master lonely open spaces of the code in loneliness..." That eludes me for
> example.
> "Apparently, SciTE gets to the sad list of projects where new forces should
> master lonely open spaces of the code in loneliness..." That eludes me for
> example.
It is very poetic - that was the one part I understood!
steve d.
Mingun
Nov 17, 2010, 7:18:00 AM11/17/10
to scite-interest
I understand that evil, but unfortunately...
Sense:
1. The code absolutely without comments, it is necessary to study
hours it to understand, how it works.
2. Nobody tells, why it so is made, hence, if something to change,
something can fail in other place. And, it is not clear where - as
there is no documentation.
I hope, clearly :)
Sense:
1. The code absolutely without comments, it is necessary to study
hours it to understand, how it works.
2. Nobody tells, why it so is made, hence, if something to change,
something can fail in other place. And, it is not clear where - as
there is no documentation.
I hope, clearly :)
Philippe Lhoste
Nov 17, 2010, 7:37:46 AM11/17/10
to scite-i...@googlegroups.com
On 17/11/2010 13:18, Mingun wrote:
> 1. The code absolutely without comments,
> 1. The code absolutely without comments,
A bit exaggerated... There was even an attempt to support Doxygen doc comments, but lack
of time, motivation, etc. left that half done.
> it is necessary to study
> hours it to understand, how it works.
Still true, although most of the names used in the code are quite self-describing (unlike
some old C programs...).
> 2. Nobody tells, why it so is made, hence, if something to change,
> something can fail in other place. And, it is not clear where - as
> there is no documentation.
Developer's doc., I suppose. I won't disagree here, and your attempt is appreciated.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Mingun
Nov 17, 2010, 7:39:00 AM11/17/10
to scite-interest
Has forgotten one piece:
The built-in scripting engine.
As I was convinced, now its implementation, unfortunately, it is
represented code jumble in one .cxx-file. The table scite, objects
editor and output, global functions print, _ASSERT, etc., redefined to
conduct an output in SciTE console, are placed in one file. To
understand this chaos very heavily. Also in the same file static
variables that does inconvenient sharing of this file on some separate
units are declared. Here lacks singleton for a host of extensions
(static ExtensionAPI* host now in the code) and the manager of
extensions (i.e. ExtensionManager::getSingleton().<method>, see OGRE
(www.ogre3d.org) ideology).
While it is everything that I wanted to inform. As there will be new
thoughts on (current) structure of SciTE, I will update this post. I
hope, my experience is useful to those who will decide to test in a
field of improving SciTE[-Ru]
Original message (in Russian) here: http://www.scite-ru.org/viewtopic.php?f=11&t=43
The built-in scripting engine.
As I was convinced, now its implementation, unfortunately, it is
represented code jumble in one .cxx-file. The table scite, objects
editor and output, global functions print, _ASSERT, etc., redefined to
conduct an output in SciTE console, are placed in one file. To
understand this chaos very heavily. Also in the same file static
variables that does inconvenient sharing of this file on some separate
units are declared. Here lacks singleton for a host of extensions
(static ExtensionAPI* host now in the code) and the manager of
extensions (i.e. ExtensionManager::getSingleton().<method>, see OGRE
(www.ogre3d.org) ideology).
While it is everything that I wanted to inform. As there will be new
thoughts on (current) structure of SciTE, I will update this post. I
hope, my experience is useful to those who will decide to test in a
field of improving SciTE[-Ru]
Original message (in Russian) here: http://www.scite-ru.org/viewtopic.php?f=11&t=43
Mingun
Nov 17, 2010, 7:55:10 AM11/17/10
to scite-interest
It is simple to support Doxygen documentation in a normal kind if to
do at once after code writing. Now, when the undocumented code has
collected a lot of, it is heavy. But it is necessary to describe it
gradually.
Speaking names it is fine, but I would prefer also something to
reading ;)
Unfortunately, the documentation of developers won't explain all
aspects. It in general describes result, not the reasons.
do at once after code writing. Now, when the undocumented code has
collected a lot of, it is heavy. But it is necessary to describe it
gradually.
Speaking names it is fine, but I would prefer also something to
reading ;)
Unfortunately, the documentation of developers won't explain all
aspects. It in general describes result, not the reasons.
KHMan
Nov 17, 2010, 9:56:06 AM11/17/10
to scite-i...@googlegroups.com
On 11/17/2010 8:55 PM, Mingun wrote:
> It is simple to support Doxygen documentation in a normal kind if to
> do at once after code writing. Now, when the undocumented code has
> collected a lot of, it is heavy. But it is necessary to describe it
> gradually.
>
> Speaking names it is fine, but I would prefer also something to
> reading ;)
>
> Unfortunately, the documentation of developers won't explain all
> aspects. It in general describes result, not the reasons.
> It is simple to support Doxygen documentation in a normal kind if to
> do at once after code writing. Now, when the undocumented code has
> collected a lot of, it is heavy. But it is necessary to describe it
> gradually.
>
> Speaking names it is fine, but I would prefer also something to
> reading ;)
>
> Unfortunately, the documentation of developers won't explain all
> aspects. It in general describes result, not the reasons.
Nice documentation? Always a dream in our eyes, my friend.
I think if there is awesome documentation, workload will more than
double. Time isn't unlimited, you know. Manpower isn't free... it
is free for the taker, not for the giver.
I'm sure we'd all like better docs. It is only fair that this is
something this community should demonstrate -- someone should try
band up some people and create and maintain some documentation for
1 year, then we're talking.
The code looks fine for experienced developers. You learn how it
all links up and you can more-or-less follow the sources. It will
not be enough for some programmers... but it's impossible to
satisfy everyone.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Reply all
Reply to author
Forward
0 new messages