• Split object into multiple files ?

    From skybuck2000@hotmail.com@21:1/5 to All on Sun Dec 29 09:34:41 2019
    Can oberon do this, or has it repeated the mistake in Delphi ?

    There is a very serious limitations in the object orientation in Delphi programming language.

    It's basically impossible to split an object into multiple files/units.

    The only method that comes somewhat close is using include files, but then those include sections cannot be debugged or searched properly by the in-memory compiler.

    Therefore I do request this feature be added to the Delphi programming language and that environment/debugging/searching/editor support for this new feature is added/supported as well.

    Bye for now,
    Skybuck.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ned Latham@21:1/5 to All on Sun Dec 29 21:54:19 2019
    skybuck2000 wrote:

    Can oberon do this, or has it repeated the mistake in Delphi ?

    There is a very serious limitations in the object orientation in
    Delphi programming language.

    It's basically impossible to split an object into multiple files/units.

    Can't you just Write() a number of bytes to file1, move forward that many bytes, Write() that many bytes to file2, and so on?

    ----snip----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From skybuck2000@hotmail.com@21:1/5 to Ned Latham on Mon Dec 30 21:48:09 2019
    On Monday, December 30, 2019 at 4:54:25 AM UTC+1, Ned Latham wrote:
    skybuck2000 wrote:

    Can oberon do this, or has it repeated the mistake in Delphi ?

    There is a very serious limitations in the object orientation in
    Delphi programming language.

    It's basically impossible to split an object into multiple files/units.

    Can't you just Write() a number of bytes to file1, move forward that many bytes, Write() that many bytes to file2, and so on?

    ----snip----

    :)

    This is about splitting source into multiple files and compiling/using them inside a development environment to be able to develop large object orientated main computer program objects without having to store all the code in one big file which is kinda
    annoying with scrolling and other environment behaviour and less convenient when some of that code wants to be hidden by programmer from view to concentrate on the more interesting code, but still needs to be there part of the whole ! ;)

    Just cleared that up for you in case I wasn't a joke ! LOL or somebody else don't get it ! LOL.

    Bye,
    skybuck ;) =D

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ned Latham@21:1/5 to All on Tue Dec 31 07:15:18 2019
    skybuck2000 wrote:
    Ned Latham wrote:
    skybuck2000 wrote:

    Can oberon do this, or has it repeated the mistake in Delphi ?

    There is a very serious limitations in the object orientation in
    Delphi programming language.

    It's basically impossible to split an object into multiple files/units.

    Can't you just Write() a number of bytes to file1, move forward that many bytes, Write() that many bytes to file2, and so on?

    This is about splitting source into multiple files and
    compiling/using them inside a development environment to be able
    to develop large object orientated main computer program objects
    without having to store all the code in one big file which is
    kinda annoying with scrolling and other environment behaviour and
    less convenient when some of that code wants to be hidden by
    programmer from view to concentrate on the more interesting code,
    but still needs to be there part of the whole ! ;)

    For compiling it should be easy: decide on a splitfile size, divide
    the composite file's size by that for the number of splitfiles then
    split the file into that many pieces of that size, giving each a
    filename of the pattern splifile_nnn, where nnn is the file's number
    in the sequence in leading-zero notation so that the system accesses
    them in the order you want.

    Restoring it is just a matter of concatenating them.

    Dunno about editing. Do you have a development environment or an
    editor that offers buffered file access (like vim, for example)?

    My development environment is g++, vim, X, blackbox, and xterm.
    For programming I keep 6 xterms open on each desktop, each of
    them having a different file open in vim. If you could do that
    or something like it with your collection of splitfiles, you
    might have a very low-maintence solution. The splitfile size
    is needed only to generate the splitfileis efficiently, now
    their size doesn't matter. If you edit splitfile_003.ext, for
    example, that edit is what goes into the contcatenation, no
    matter what the resultant size of splitfile.003.ext is. So
    by editing the splitfiles, you're editing what has become your
    original source code,

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From skybuck2000@hotmail.com@21:1/5 to Ned Latham on Tue Jan 7 15:04:08 2020
    On Tuesday, December 31, 2019 at 2:15:23 PM UTC+1, Ned Latham wrote:
    skybuck2000 wrote:
    Ned Latham wrote:
    skybuck2000 wrote:

    Can oberon do this, or has it repeated the mistake in Delphi ?

    There is a very serious limitations in the object orientation in
    Delphi programming language.

    It's basically impossible to split an object into multiple files/units.

    Can't you just Write() a number of bytes to file1, move forward that many bytes, Write() that many bytes to file2, and so on?

    This is about splitting source into multiple files and
    compiling/using them inside a development environment to be able
    to develop large object orientated main computer program objects
    without having to store all the code in one big file which is
    kinda annoying with scrolling and other environment behaviour and
    less convenient when some of that code wants to be hidden by
    programmer from view to concentrate on the more interesting code,
    but still needs to be there part of the whole ! ;)

    For compiling it should be easy: decide on a splitfile size, divide
    the composite file's size by that for the number of splitfiles then
    split the file into that many pieces of that size, giving each a
    filename of the pattern splifile_nnn, where nnn is the file's number
    in the sequence in leading-zero notation so that the system accesses
    them in the order you want.

    Restoring it is just a matter of concatenating them.

    Dunno about editing. Do you have a development environment or an
    editor that offers buffered file access (like vim, for example)?

    My development environment is g++, vim, X, blackbox, and xterm.
    For programming I keep 6 xterms open on each desktop, each of
    them having a different file open in vim. If you could do that
    or something like it with your collection of splitfiles, you
    might have a very low-maintence solution. The splitfile size
    is needed only to generate the splitfileis efficiently, now
    their size doesn't matter. If you edit splitfile_003.ext, for
    example, that edit is what goes into the contcatenation, no
    matter what the resultant size of splitfile.003.ext is. So
    by editing the splitfiles, you're editing what has become your
    original source code,

    The IDE, integrated development environment, must also be able to do:

    1. Syntax highlighting
    2. Debugging
    3. Find declaration, so in-memory compiling.
    4. Code insight/Code completion.

    So there are many things that are affected by this.

    For practical usage the IDE will have to support this splitting, by supporting the splitting in every possible way :)

    Otherwise splitting the files/object becomes unpractical ;) :)

    Bye,
    Skybuck =D

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ned Latham@21:1/5 to skybuck2000@hotmail.com on Tue Jan 7 17:48:55 2020
    skybuck2000@hotmail.com wrote in <b6eedc0b-e1b2-47ec-8b02-8269766624a3@googlegroups.com>:
    On Tuesday, December 31, 2019 at 2:15:23 PM UTC+1, Ned Latham wrote:
    skybuck2000 wrote:
    Ned Latham wrote:
    skybuck2000 wrote:

    Can oberon do this, or has it repeated the mistake in Delphi ?

    There is a very serious limitations in the object orientation in Delphi programming language.

    It's basically impossible to split an object into multiple files/units.

    Can't you just Write() a number of bytes to file1, move forward that many
    bytes, Write() that many bytes to file2, and so on?

    This is about splitting source into multiple files and
    compiling/using them inside a development environment to be able
    to develop large object orientated main computer program objects
    without having to store all the code in one big file which is
    kinda annoying with scrolling and other environment behaviour and
    less convenient when some of that code wants to be hidden by
    programmer from view to concentrate on the more interesting code,
    but still needs to be there part of the whole ! ;)

    For compiling it should be easy: decide on a splitfile size, divide
    the composite file's size by that for the number of splitfiles then
    split the file into that many pieces of that size, giving each a
    filename of the pattern splifile_nnn, where nnn is the file's number
    in the sequence in leading-zero notation so that the system accesses
    them in the order you want.

    Restoring it is just a matter of concatenating them.

    Dunno about editing. Do you have a development environment or an
    editor that offers buffered file access (like vim, for example)?

    My development environment is g++, vim, X, blackbox, and xterm.
    For programming I keep 6 xterms open on each desktop, each of
    them having a different file open in vim. If you could do that
    or something like it with your collection of splitfiles, you
    might have a very low-maintence solution. The splitfile size
    is needed only to generate the splitfileis efficiently, now
    their size doesn't matter. If you edit splitfile_003.ext, for
    example, that edit is what goes into the contcatenation, no
    matter what the resultant size of splitfile.003.ext is. So
    by editing the splitfiles, you're editing what has become your
    original source code,

    The IDE, integrated development environment, must also be able to do:

    1. Syntax highlighting

    Don't be ridiculous. If you think you need that, you need to rethink.

    2. Debugging

    Try careful programming.

    3. Find declaration,

    grep

    so in-memory compiling.

    Everything computers do is "in memory".

    4. Code insight/Code completion.

    Multiple xterms. For compiling, something like

    cat splitfile_???.ext > temp.ext ; gcc temp.ext ; rm temp.ext

    So there are many things that are affected by this.

    For practical usage the IDE will have to support this splitting,
    by supporting the splitting in every possible way :)

    Read above, "My development environment is ..."

    Otherwise splitting the files/object becomes unpractical ;) :)

    I've never seen any need for it. Modularisation's all you need.

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