Potential Grammar Fail

While reading a description of a book, I came across this passage:

[The Author] skips ahead years at a time, often eliding major conflict resolutions, character development and deaths...

The present participle eliding comes from the root elide, which is defined by most reputable dictionaries as:

1. Omit, or
2. Merge

As one can see, elide can mean one of two distinct things. Either you omit something or you bring two or more things together.  So, which one did the review writer mean?  Here is the same quote with each definition in place of eliding:

[The Author] skips ahead years at a time, often omitting major conflict resolutions, character development and deaths...

[The Author] skips ahead years at a time, often merging major conflict resolutions, character development and deaths...

Sadly, each meaning of elide works, and this is why the use of eliding in this text—without further clarification—is a grammar FAIL.  Fortunately, there is a clue to the real meaning later in the passage.  Here is the more complete quote with the clue:

[The Author] skips ahead years at a time, often eliding major conflict resolutions, character development and deaths; this choice disrupts the storytelling but smartly underscores the isolation in which the characters often operate.

It is not crystal clear, but one can safely surmise that the use of eliding, paired with isolation, indicates omissions. Yea! We figured it out!

Bring on the cake!

The problem, and in my opinion still a Fail, is that the reader needs to backtrack from "isolation" to "eliding" in order to glean an appropriate understanding of the description's real meaning. It would have been so much clearer and simpler if, instead of "eliding", the author of the description instead used "omitting" or "merging", or some similar version thereof.

Notes From the Edge of Depression

Just a quick note before I crawl away and expire.  I've noticed that I tend to write better when I get hit with depression.  And, I don't mean I somehow write gloriously or with an otherworldly ability for organization, character arc, or accuracy.  I mean that words tend to pour out of my head in bursts and--if I am of a keen enough mind to remember--I am able to craft short memos or missives that tend to sound a bit silly, yet magically contain a very nice cadence.

I have often taken these silly things and worked on them later when I was not so depressed, and I found that I liked the results.  When I am not depressed, words fail me, but I can maintain a fair amount of concentration and mien whilst editing or restructuring.

Now, if I can only harness that process with due diligence, I might actually be able to START that Great American Novel I have been pining to write for the past 30 years or so.

<grins>

Right.  Well, back to my depressing day...

Finer Points in Java: Shadowing vs Overriding

I have recently run into a "feature" of Java which really caused me a lot of head scratching and testing before I discovered the core of a recent coding problem.  Because I was unclear of certain peculiarities of shadowing and overriding, I was expecting A, when in fact I got B.

The Problem

In a nutshell, shadowed variables come from the declared type of an object, but overridden methods are run from the constructed object.

Ok, that isn't very clear, so here is some code to make it simpler.  It's all in one file called Derived.java:

class Base {
    public int x = 0;
    public String aMethod() {
        return "Base";
    };
}

public class Derived extends Base {
    private String secretmessage = "a secret!";
    public int x = 1;
    public String aMethod() {
        return "Derived " + this.secretmessage;
    }
    
    public static void main(String[] args) {
        Base b = new Derived();
        //
        System.out.println("x:aMethod = " + b.x + ":" + b.aMethod());
        //
    }
}

The output of this when run is:

x:aMethod = 0:Derived a secret!

What that shows is that b.x returned the Base class's variable x, and b.aMethod() returned the Derived class's method aMethod.

Access to Unreachable Data

In Derived, the function aMethod returns a string that contains the contents of the private instance variable secretmessage.  If I were to substitute b.aMethod() with b.secretmessage, I would get a compiler error because b.secretmessage is not available in class B:

Derived.java:23: error: cannot find symbol
        System.out.println("x:aMethod = " + b.x + ":" + b.secretmessage);
                                                         ^
  symbol:   variable secretmessage
  location: variable b of type Base
1 error

But, I can access the variable via aMethod!  This also means I could execute any method in Derived, as long as it overrides the same method in Base.

If an able Java programmer did not know this, then reading the code may be problematic: one would expect a base class's method to run when in fact the derived class method was run.  Likewise, the opposite could be said for a shadowed variable.

Bottom line: be aware of the shadowing and overriding rules.

Updating Table From Another Table With Row Mismatch

I currently work with financial software based, mainly, in stored procedures in a few Microsoft SQL Server databases.  A lot of my efforts are directed toward maintaining the current processes while integrating enhancements and modifications whenever possible.

Recently, I ran into a problem with an UPDATE statement.  Here is the way the update process was built:

with CTE_1 as (...),
CTE_2 as (...)
    update TargetTable
    set
        Value_1 = case c.TransType when 1 then c.ComputedAmt else Value_1,
        Value_2 = case c.TransType when 2 then c.ComputedAmt else Value_2            
    from
        CTE_x c
    where
        TargetTable.Key = c.Key

My intention was simple: update one column when the transaction type was one value, and update another column when the transaction type was another value.  But, it failed.  Let's take a look at the data generated in the CTE section for table CTE_x (that being either CTE_1 or CTE_2):

Key	TransType	ComputedAmt
ABC01	1	123.45
ABC01	2	989.02
EFG33	1	34.00
EFG33	2	3024.63

...

Now take a look at how TargetTable is populated:

Key	Value_1	Value_2
ABC01	0.00	0.00
EFG33	0.00	0.00

...

The problem with the UPDATE statement above is that I want to update each row in the target table twice.  This is forbidden.

The solution was to add another CTE that took the data from CTE_x and pivoted it so that I would have a one-to-one relationship between the target table and the source of the updates:

with ...
,
CTE_pivot as (
        select
            Key as "SourceKey",
            [1] as "VAL_a",[2] as "VAL_b"
        from (select Key,TransType,ComputedAmt from CTE_x) as x
        pivot (
            max(ComputedAmt)
            for TransType in ([1],[2])
        ) as pvt
)

With the pivoted data now in CTE_pivot, the data was correctly organized thusly:

Key	VAL_a	VAL_b
ABC01	123.45	989.02
EFG33	34.00	3024.63

...


And with this, the final UPDATE statement gets a single row with both columns from the source table (now CTE_pivot):

with ...
update TargetTable
  set Value_1 = VAL_a, Value_2 = VAL_b
from
  CTE_pivot
where
  CTE_pivot.Key = TargetTable.Key