Re: One good argument against using "with"

Adem wrote:
Charles McAllister wrote:

I don't know if its unsurmountable, but it is going to be difficult
to save everything and be able to load it back into the tree just
as before (I'm speaking of the interfaces in IcwInterfaces.pas).
This is because everything is linked together through an interface
pointer reference, which obviously cannot be persisted.


Oh, no.. Is there any reason those interfaces couln't be made TPersistent
with virtual abstract methods?

Good thinking <g>. Yes I've thought of that, and I started to make each class descend from a TPersistent, with refcounting removed. But backed out of my changes because of the other issues I talked about above.


IMHO, CodeLense infrastructure is blazingly fast, I very much doubt
file I/O (saving and loading *.cwu) can beat CW's parsing speed.

The largest single pas file I have so far seen hasn't been bigger
than 1.5 MB (save the one I autogenerated couple of weeks ago which
was 133 MB and choked Delphi --we won't go into that <g>).

So, no, I would not go that route. In memory should be good enough.

Yeah it's good enough for me. But something would have to be done, if its going to integrated into the IDE, where refactorings could be done many times throughout the day without having to reparse every single unit. How about requiring a full parse when you first use the expert, then the expert would pay attention to what units are altered in the IDE throughout the day, and only re-parse those units. There could be some killer experts made using CW, like on the scale of CodeRush.

But, I'd really like to know your opinion/stance on turning
every Interface into a TPersistent (or TObject at worst).

There are several options. One idea would be to make a TPersistent descendant that would aggregate the interface, and publish what it needs.

When you parse a project in CW, you get a tree view of symbols it
has gathered. These symbols are defined in ucwInterfaces.pas.
But these interfaces (and the classes that implement them) don't
keep any of the whitespace, and comments in each unit. So its
not possible to re-generate the source code using these interfaces.


Not much of a problem. What I had in mind was, a more intelligent
search and replace (refactoring) that would have to be scope-aware.
For this type of thing, it would help (for speed) that token location
be known.

This would make a really nice expert in Delphi's IDE. Have a little window docked that would show scope-aware search results. Does Delphi 2006 have this? I think I could use this like 100 times a day <g>.

What I did then was create a set of classes that represent a hierarchy
of sections in the source code, and these classes do preserve all of
the source code. These classes are found in ucwRefactorNodes.pas.
You can use the RefactorNodeTreeView.bpl plugin to see how a unit
gets parsed into these classes.


Yes, I did see that. What I did not check or see was whether references
to classes (or methods) derive/override from base classes (and from
other units). I suppose it is there, or else 'unwith'ing wouldn't work.

IcwClass has a property called InheritsFromClass. It also has a Descendants property.
Un-withing does look at the current class and all ancestors.

Cheers,
Adem
.

Relevant Pages

  • Re: Extending ATL COM Object Dual Interfaces
    ... providing you have the source code. ... > I have a need to extend existing CoClass functionality with dual ... the CoClass must contain dual interfaces to ... > support scripting clients as well as vTable support for early binding. ...
    (microsoft.public.vc.atl)
  • Re: Fedora Desktop future- RedHat moves
    ... I could have gotten a copy of the source code that it's own author and the experts involved in the OS packaging couldn't fix. ... But if you walk away from your interfaces particularly without supplying replacements for the things that will break, no one can be expected to trust you. ... I do recall reading about some issues with firewire but never ...
    (Fedora)
  • Re: CLR details- Are MSCorEE.dll and MSCorWks.dllMSCorSvr.dll COM
    ... I'm having a source code license and I'm not interested ... Also tlb files do not ... necessarily represent accurately the COM interfaces of a COM server, ...
    (microsoft.public.dotnet.framework.clr)
  • Re: [PATCH] char: Add Dell Systems Management Base driver
    ... > systems management software that access the interfaces are ... > source code for the software. ... > following Dell proprietary hardware systems management interfaces: ...
    (Linux-Kernel)